VMware Data Recovery (CD ISO)
Released 11/19/09 | Version 1.1 | Size 418 MB | Binary (.iso)
Deploy VMware Data Recovery virtual appliance plus management components.
SHA1SUM 44dc0cd0c3e774d4912412b51dabeadf28d959b9
The vDS UI also allows a phased migration of vmnics from vSS to vDS without disruption to an operational environment. VMs can be migrated from a vSS to a vDS on the fly so long as the vDS and vSS have connectivity to the same network at the same time and the origin Port Group on the vSS and destination DV Port Group on the vDS are configured to the same VLAN.
Host Profiles provide a way to migrate multiple hosts at one time. Host Profiles use a golden profile from a migrated host to propagate a configuration to a number of other hosts.
When applying a Host Profile to a host, the host must be in Maintenance Mode. This requires VMs to be either powered down or migrated to another host.
Host Profiles are most appropriate for new installations of similarly configured hosts (i.e. same number of vmnics, same vmnic to physical switch configuration, no active VMS).
The table below summarizes the deployment situations and suggested methods for migration from vSS to vDS. Note: These are suggestions only; both methods will work within the guidelines mentioned above.
Table 1 – Summary of vSS to vDS Migration Methods
| DeploymentSituation | SuggestedMethod | Details |
| New servers, same vmnic config, no active VMs | vDS UI + HP | Migrate first host with vDS UI. Take host profile and apply to remaining hosts |
| <5 Existing Servers, no active VMs | vDS UI | Small number of servers. Can use host profiles, but possibly easier to continue with vDS UI |
| >5 Existing servers, same vmnic configs, no active VMs | vDS UI + HP | Larger number of servers with similar vmnic configuration. No active VMs so can enter maintenance mode and use Host Profiles |
| Existing Servers, active/operational VMs | vDS UI | Cannot use Maintenance Mode as VMs active. Phased vmnic migration suggested to ensurecontinuity of VM communications |
| Existing Servers, dissimilar vmnic configurations | vDS UI | Enables per host tailoring of vmnic to dvUplink PortGroup mapping |
| Ongoing Compliance Checking | HP | Non-disruptively check network settings are compliant with approved “golden” configuration |
Note: vDS UI = Use vDS UI; HP = use Host Profiles; vDS + HP = use vDS UI to deploy first host and Host Profiles for remaining hosts.
Applying NIC Teaming Policies to DV Port Groups With a vSS, NIC teaming policies are defined on the virtual switch with an optional override on each Port Group definition. With vDS, NIC teaming policies are only defined on the DV Port Groups and apply to dvUplinks, not vmnics. The vmnics are mapped to the dvUplinks on a per host basis. This enables each host to have a different vmnic to physical host configuration and yet use the same NIC teaming policy over all hosts spanned by the vDS.
The esxtop command from the ESX console can reveal the physical NIC (vmnic) used by virtual port or VM within a NIC team.
Use esxtop to see the following information:
To use esxtop, type esxtop from the ESX console and then type n.
A list of commands for the ESX command line interface is published in Chapter 6 of the ESX 4.0 Configuration Guide (available at http://www.vmware.com/support/pubs/). To control console output to one page at a time by adding the | more suffix to the commands. For example:
esxcfg-vswitch –l | more
Reference: http://vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf
(See page 8)
VMware just updated their KB: Reserved or overhead ports for virtual switches (http://kb.vmware.com/kb/1008040) and we’ve run into this issue a number of times since upgrading to vSphere ESX 4. These new high memory hardware architectures allow an unprecedented number of virtual machine guests to be consolidated on a single ESX host.
By default a vswitch may not have enough ports to support the consolidation ratio your equipment can support. New ESX hosts can have 256 GB of RAM with 4 hex core processors and easily support 100 or more virtual machines. These virtual machines might have 1, 2, or more vNICs configured and each would need a port on the vswitch. One might imagine the need for 500 to 1000 ports needed per esx host. Why not just make it 2000 so we don’t have to worry about it later on?
Once you run out of vswitch ports you cannot power on any more vms on that host and even get errors about unplugged network cable. Increasing the vSwitch port allocation seems easy enough, vmotion all workload off the host, put it in maintenance mode, change the vswitch config, reboot. Some system administrators run into this issue and decide to make the number of ports allocated to the vswitch really high to prevent this from ever being an issue. This can cause problems though.
There’s a limit of how many vswitch ports in total an ESX host has to hand out to it’s various vswitches. In addition, if security is a concern, you may start running firewall virtual appliances like vShield Zones or Catbird. WAN Accerators and Performance Monitoring tools like AppSpeed also require additional vSwitches to be created. Ports used on these vSwitches all take away from the total bucket of available ports.
Once 4096 ports are allocated to existing vSwitches you will not be able to add additional hosts to a vNetwork Distributed Switch either.
We also have the following Security Recommendation:
This will make it difficult if not impossible to “plug” a VM into the wrong network by accident. Testing for this can be done manually through the vSphere Client. If there are no ports available on a vSwitch then this is a positive test.
1. While connected to the vCenter Server Navigate to Home – Inventory – Networking in the vSphere Client and click on the vDS in question.
2. Click on the Ports Tab
3. If all of the ports in the list have a VM associated with it in the “connected”column then this is a positive test.
Deployment scenarios where a very large number of uplinks are teamed together on a single virtual switch might significantly impact the number of ports on that virtual switch available for virtual machine use, and the overall size of the virtual switch might need to be adjusted accordingly.
The current port utilization data for virtual switches can be reviewed by using the esxcfg-vswitch –list command.
The current overhead utilization on a given virtual switch can be calculated by subtracting the Used Ports value for all PortGroups from the Used Ports value for that virtual switch.
Recommendation: Use VNDS vNetwork distributed Switches for all Virtual Machine traffic and limit the number of ports assigned to each standard vSwitch used for vmkernel and service console.
Note: A server reboot is required to apply the following configuration change. Migrate the virtual machines off the ESX host to prevent any downtime. On the vswitch there is an option to specify the number of ports the vswitch supports.
To view this setting:
The Open Virtualization Format (OVF) specification is a standard being developed within the Distributed Management Task Force (DMTF) association to promote an open, secure, portable, efficient, and extensible format for the packaging and distribution of software to be run in virtual machines.
For use within an organization, Level 1 or Level 2 compatibility may be good enough, since the OVF package is distributed within a controlled environment where specific purchasing decisions of hardware or virtualization platforms can ensure consistency of the underlying feature set for the OVF.
Level 1. Only runs on a particular virtualization product and/or CPU architecture and/or virtual hardware selection. This would typically be due to the OVF containing suspended virtual machines or snapshots of powered on virtual machines, including the current run-time state of the CPU and real or emulated devices. Such state ties the OVF to a very specific virtualization and hardware platform.
You can export a virtual machine to a virtual appliance, making it available to other users to import into their inventories. The resulting virtual appliance is an OVF 1.0 appliance and contains one virtual machine. OVF Virtual Appliances contain many files that are typically compressed into an archive that can be put on removable media or downloaded from a server. This file much be decompressed prior to being imported and is more cumbersome to use. Consider using OVA for internal enterprise use.
You cannot select a virtual appliance destination for physical machine sources or virtual appliance sources.
You can now select the destination for your new virtual machine.
You selected to export a virtual machine to a virtual appliance.
On the View/Edit Options page, you can make more precise settings to the conversion task.
Start the Deploy OVF Template Wizard
You deploy an OVF template with the Deploy OVF Template wizard.
Select File > Deploy OVF Template
http://blogs.vmware.com/vapp/2009/08/inside-the-ovf-package.html
Iben Rodriguez
+14082188957
SUMMARY: For best performance be sure to upgrade your VMFS Block Storage when you upgrade your ESX hosts to vSphere.
VMFS 3 versions and upgrade paths
http://www.vfrank.org/2010/01/31/vmfs-3-versions-maybe-you-should-upgrade-your-vmfs/
http://virtualizationreview.com/blogs/everyday-virtualization/2009/06/vstorage-vmfs-version-notes.aspx
http://communities.vmware.com/message/1071323
http://www.onlinetechblog.com/blog/index.php/2009/11/vsphere-4-0-places-service-console-in-local-vmfs-volume/
esx network ports
The amazing Dudley Smith, from VMware’s Technical Account Manager team has release a larger version of his vSphere Network Connections and Ports for ESX diagram and an accompanying excel spreadsheet listing all the TCP/IP ports for various communication purposes.
Get them directly from the VMware blog site here:
HyTrust Appliance 2.0 is available. Building on the successes of 2009, which included our initial product launch and numerous awards, we’re happy to see the streak continue into 2010 by delivering a major new release that will empower enterprises to capitalize on the wave of datacenter virtualization and accelerate efforts to virtualize tier-one applications. The features available in HyTrust Appliance 2.0 deliver true enterprise-class policy management and access control capabilities to virtual infrastructure. New features include the following:
* Root Password Vault: Locks down privileged host accounts and provides passwords for temporary use to enable time-limited privileged account access. Root accounts on hypervisors are extremely powerful and, as a consequence, can create a significant liability if not kept out of the wrong hands. With the aid of Root Password Vault, all root account access is attributable to an individual and every action is logged, providing far greater visibility and accountability.
* Federated Deployment: Secure distributed system architecture allows for automated replication of policies and templates across multiple HyTrust Appliances as well as geographic boundaries. For larger enterprises with multiple datacenters and collocation facilities, Federated Deployment of HyTrust Appliances ensures consistency of controls across the entire infrastructure.
* Virtual Infrastructure Search: Enables quick and easy accessibility to all virtual infrastructure objects, policies, and logs within HyTrust Appliance.
* Remote API: Interface to remotely access and automate the administration of the HyTrust Appliance. Provides the greater scalability demanded by large, enterprise-wide deployments of virtualization.
* Object Policy Labels: Creates a policy categorization structure, similar to “Web 2.0 tagging” for virtual infrastructure objects, which enables better organization and tighter, more consistent controls. Object Policy Labels enable access, network segment, and zoning policies, which allows administrators to dictate which virtual machines are allowed to connect to which network segments or hosts via RuleSets and Constraints.
* Router-Mode: a deployment option where all VMware management traffic is forced to flow through the HyTrust Appliance. HyTrust Appliance acts as a router for the “protected” management subnet and ESX/ESXi hosts and vCenter Server use HyTrust Appliance as their default gateway. This adds yet another flexible deployment option to the other existing options, ensuring the HyTrust Appliance will easily adapt to any enterprise architecture.
Along with the new capabilities delivered in 2.0, we’d like to introduce you to the new editions of HyTrust Appliance:
* Community Edition is a free version of the product that supports up to three hosts.
* Standard Edition supports an unlimited number of hosts and offers more flexible deployment options.
* Enterprise Edition supports an unlimited number of hosts, offers more flexible deployment options, supports federation of multiple HyTrust Appliances, enables privileged account management via Root Password Vault, allows two-factor authentication, and offers a remote API for additional management flexibility.
You can download the Community Edition of HyTrust Appliance at http://www.hytrust.com/community.
From http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esx_server_config.pdf <— look on page 98 or the VMware ESXi Configuration Guide
Network Attached Storage
ESX supports using NAS through the NFS protocol. The NFS protocol enables communication between an NFS client and an NFS server.
The NFS client built into ESX lets you access the NFS server and use NFS volumes for storage. ESX supports only NFS Version 3 over TCP.
You use the vSphere Client to configure NFS volumes as datastores. Configured NFS datastores appear in the vSphere Client, and you can use them to store virtual disk files in the same way that you use VMFS-based datastores.
*** NOTE: ESXi does not support the delegate user functionality that enables access to NFS volumes using non- root credentials.
Also see these links for more info on read only capabilities for different licenses.
http://partnerweb.vmware.com/comp_guide/docs/vSphere_Comp_Matrix.pdf
On the ViOPs site there is a comparison matrix of ESXi/ESX in case we’re asked ‘which one should I use?’.
VMware ESX and ESXi 4.0 Comparison – http://kb.vmware.com/kb/1015000
VMware ESX and ESXi 3.5 Comparison – http://kb.vmware.com/kb/1006543
RCLI is limited to read-only access for the free version of VMware ESXi. To enable full functionality of RCLI on a VMware ESXi host, the host must be licensed with VI Foundation, VI Standard, or VI Enterprise.
http://www.vmware.com/products/vsphere/buy/editions_comparison.html
Comparison of product offerings for vSphere 4.0 and VMware Infrastructure 3.X – http://kb.vmware.com/kb/1010579
Glad to see this has been posted and we can talk about it now… please share your experiences and let us know if these tips work for you and what sort of performance benefits you’ve noticed when using this new driver.
We’ve been switching our Windows and Linux VMs to use “VMXNET Enhanced” for some time now and see public information on the new VMXNET3 NIC for guests…
This Thread has been started to help with procedures on the conversion of existing machines from older NIC to newer NIC as it is not 100% straightforward and there are some tricks to remove old hardware and change to new hardware. This would be similar in the physical world to changing from a 100 BaseT PCI Card to a GigE card. The old drivers need to be removed, new drivers installed, and IP Addresses moved over. If you just remove the old NIC and install the new one you may end up with a IP Address Conflict error saying the Address you are trying to use is already in use on another Network Interface. The problem is that when you open Device Manager the old NIC is hidden. See below for steps on how to overcome this.
Question: What is VMXNET3?
Answer: VMXNET3 builds upon VMXNET and Enhanced VMXNET as the third generation paravirtualized virtual networking NIC for guest operating systems.
New VMXNET3 features over previous version of Enhanced VMXNET include:
• MSI/MSI-X support (subject to guest operating system kernel support)
• Receive Side Scaling (supported in Windows 2008 when explicitly enabled through the device’s Advanced configuration tab)
• IPv6 checksum and TCP Segmentation Offloading (TSO) over IPv6
• VLAN off-loading
• Large TX/RX ring sizes (configured from within the virtual machine)
What’s New in vSphere 4.0
http://communities.vmware.com/viewwebdoc.jspa?documentID=DOC-9225&communityID=2701
http://www.vmware.com/files/pdf/VMW_09Q1_WP_vSphereNetworking_P8_R1.pdf
From the Cisco document:VMware vSphere 4 and Cisco Nexus 1000V Series
VMware vNetwork module that encompasses the vDS and VMXNET-3 enables inline monitoring and centralized firewall services and maintains the virtualmachine’s network run-time characteristics.
Flexible shows up in Windows Device Manager as an “VMware
Accelerated AMD PCNet Adapter” and Enhanced vmxnet show up as “VMware
PCI Ethernet Adapter”.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805
Flexible — The Flexible network adapter
identifies itself as a Vlance adapter when a virtual machine boots, but
initializes itself and functions as either a Vlance or a vmxnet
adapter, depending which driver initializes it. VMware Tools versions
recent enough to know about the Flexible network adapter include the
vmxnet driver but identify it as an updated Vlance driver, so the guest
operating system uses that driver. When using the Flexible network
adapter, you can have vmxnet performance when sufficiently recent
VMware tools are installed. When an older version of VMware Tools is
installed, the Flexible adapter uses the Vlance adapter (with Vlance
performance) rather than giving no network capability at all when it
can’t find the vmxnet adapter.
Enhanced vmxnet — The enhanced vmxnet adapter is
based on the vmxnet adapter but provides some high-performance features
commonly used on modern networks, such as jumbo frames. This virtual
network adapter is the current state-of-the-art device in virtual
network adapter performance, but it is available only for some guest
operating systems on ESX Server 3.5. This network adapter will become
available for additional guest operating systems in the future.
Solution
Under certain conditions, you may see the following error message from a Windows guest operating system:
The IP address XXX.XXX.XXX.XXX you have entered for this network
adapter is already assigned to another adapter Name of adapter. Name of
adapter is hidden from the network and Dial-up Connections folder
because it is not physically in the computer or is a legacy adapter
that is not working. If the same address is assigned to both adapters
and they become active, only one of them will use this address. This
may result in incorrect system configuration. Do you want to enter a
different IP address for this adapter in the list of IP addresses in
the advanced dialog box?
In this message, XXX.XXX.XXX.XXX is an IP address that you are
trying to set and Name of adapter is the name of a network adapter that
is present in the registry but hidden in Device Manager.
This can occur when you change a network connection’s TCP/IP configuration from DHCP to a static IP address if:
when you migrate a virtual machine from an older to a new version of
VMware software.)
The cause of the error is that a network adapter with the same IP
address is in the Windows registry but is hidden in the Device Manager
(My Computer > Properties > Hardware > Device Manager). This
hidden adapter is called a ghosted network adapter.
Using the Show hidden devices option in the Device Manager (View
(ghosted adapter) to which that IP Address is assigned
Microsoft addresses this issue in their Knowledge Base article
269155, which is available at the time of this writing at
http://support.microsoft.com/?kbid=269155.
To resolve this problem, follow these steps to make the ghosted
network adapter visible in the Device Manager and uninstall the ghosted
network adapter from the registry:
1. Select Start > Run.
2. Enter cmd.exe and press Enter.
3. At the command prompt, run this command:
set devmgr_show_nonpresent_devices=1
4. Enter Start DEVMGMT.MSC and press Enter to start Device Manager.
5. Select View > Show Hidden Devices.
6. Expand the Network Adapters tree (select the plus sign next to the Network adapters entry).
7. Right-click the dimmed network adapter, and then select Uninstall.
8. Close Device Manager.
Reference: http://vmtoday.com/2009/11/vsphere-upgrade-breaks-active-directory/
http://blogs.vmware.com/networking/2009/04/considerations-for-maximum-network-performance.html
For UDP, use vmxnet3 to be able to configure a larger vNIC Rx ring size. Because UDP can be a lot more bursty (due to lack of flow-control), having a larger Rx ring size helps to provide buffering/elasticity to better absorb the bursts. The new vmxnet3 allows resizing the vNIC’s Rx ring size, up to around 1 to 2 thousand buffers. As a side note, there is some negative performance impact with larger ring size due to larger memory foot print. The new vxmnet3 vNIC is more efficient than the e1000 vNIC. Also in general, ESX 4 has some performance improvements over ESX 3.5.
Howie Xu, Director of R&D for VMkernel IO remarked recently that after talking with a few customers, many are still unaware we can achieve line rate 10GigE performance on ESX 3.5. Read “10Gbps Networking Performance on ESX 3.5u1” posted on VMware’s network technology resources page.
The story only gets better with vSphere 4 and ESX 4 with the new Intel Nehalem processors. Initial tests from engineering show a staggering 30Gbps throughput.
|
|||||||
 |
|||||||
|
|||||||
|
|||||||
|
The Virtual Machine wizard’s Choose Networks window allows you to specify a network and a network adapter. The network adapter choices available depend on these factors:
The Choose Networks window makes available only those network adapters that make sense for the virtual machine you are creating. Each adapter type is discussed in some detail in “Available Network Adapters,” below. Here is an overview of what Choose Networks might offer you:
|
|||||||
|
|||||||
|
|||||||
|
Available Network Adapters
The following network adapters might be available for your virtual machine, depending on the factors discussed above:
Adapter Caveats
This section discusses some potential issues you might have.
Migrating virtual machines that use enhanced vmxnet. Enhanced vmxnet is new with ESX Server 3.5. Virtual machines configured to have enhanced vmxnet adapters cannot migrate to older ESX Server hosts, even though virtual machines can usually migrate freely between ESX Server 3.0 and ESX Server 3.0.1.
Upgrading from ESX Server 2.x to ESX Server 3.x. When a virtual hardware upgrade operation transforms a virtual machine created on an ESX Server 2.x host to an ESX Server 3.x host, Vlance adapters are automatically upgraded to Flexible. In contrast, vmxnet adapters are not upgraded automatically because certain guest operating systems — specifically most or all Linux versions — do not reliably preserve network settings when a network adapter is replaced. Because the guest operating system thinks a Flexible adapter is still Vlance, it retains the settings in that case. If the upgrade were to replace a vmxnet adapter with a Flexible adapter, the guest operating system would erroneously discard the settings.
After the virtual hardware upgrade, the network adapter is still vmxnet, without the fallback compatibility of the Flexible adapter. Just as on the original older host, if VMware Tools is uninstalled on the virtual machine, it is unable to access its network adapters.
Network adapters on multi-boot Linux. The Virtual Machine Settings dialog box and New Virtual Machine wizard allow creation of only those virtual network adapters that are supported for the selected guest operating system. If you change the guest operating system, the existing network adapters are not affected. When you switch a multi-boot Linux system between 32bit mode and 64bit mode, a problem arises because most 32bit Linux versions do not support e1000 adapters while most 64bit Linux versions support only e1000 adapters. Consider configuring your virtual machine with one of each type of network adapter (e1000 and Flexible). You can then set up your guest operating system to use only the network adapter for which it has a driver in each mode.
You can add the second adapter any time the virtual machine is powered off, but you need to change the configured guest operating system type from 32bit to 64bit or vice-versa in order to be offered the other network adapter. Since changing that setting before rebooting into the other bit depth can potentially improve the efficiency of virtual machine scheduling, plan to change the guest operating system type setting before your first reboot into the other bit depth.
Adding virtual disks. Adding an existing older (ESX Server 2.x) virtual disk to an ESX Server 3.x virtual machine results in a de-facto downgrade of that virtual machine to ESX Server 2.x. If you are using ESX Server 3.x features, such as enhanced vmxnet or Flexible network adapters, the virtual machine becomes inconsistent. When you add an existing ESX Server 2.x virtual disk to an ESX Server 3.x machine, you should immediately use the Upgrade Virtual Hardware command to restore the virtual machine to the ESX Server 3 version.
Note: Executing Upgrade Virtual Hardware changes the ESX Server 2 virtual disk so it is no longer usable on an ESX Server 2 virtual machine. Consider making a copy of the disk before you upgrade one of the two copies to ESX Server 3 format.
If you must migrate a virtual machine between newer and older hosts, do not choose enhanced vmxnet but instead one of the older adapter types. Flexible or e1000 are offered whenever enhanced vmxnet is offered. |
http://www.vmware.com/support/product_renaming.html
Old Name –> New Name
VMware VirtualCenter –> VMware vCenter Server
VMware Lifecycle Manager –> VMware vCenter Lifecycle Manager
VMware Converter –> VMware vCenter Converter
(for the version integrated into vCenter)
–> VMware vCenter Converter Standalone
(for the separately downloadable version)
VMware Lab Manager –> VMware vCenter Lab Manager
VMware Stage Manager –> VMware vCenter Stage Manager
VMware Update Manager –> VMware vCenter Update Manager
VMware Site Recovery Manager –> VMware vCenter Site Recovery Manager
VirtualCenter Foundation –> vCenter Server Foundation
VMFS –> VMware vStorage VMFS
VMware Virtual Desktop Infrastructure –> VMware View
Virtual Desktop Manager (VDM) –> VMware View Manager
VMware Administrator Interface –> VMware View Administrator
VDM Agent –> VMware View Manager Agent
VDM Web Access –> VMware View Portal
VDM Client for Windows –> VMware View Client for Windows
VDM Client for Linux –> VMware View Client for Linux
Powered by WordPress