Книга: Mastering VMware® Infrastructure3
VMotion Requirements
VMotion Requirements
The VMotion migration is pretty amazing, and when they see it work for the first time in a live environment, most people are extremely impressed. However, detailed planning is necessary for this procedure to function properly. The hosts involved in the VMotion process have to meet certain requirements, along with the virtual machines being migrated.
Each of the ESX Server hosts that are involved in VMotion must meet the following requirements:
? Shared VMFS storage for the virtual machines files
? A gigabit network card with a VMkernel port defined and enabled for VMotion on each host (see Figure 9.26 through Figure 9.32)
Perform these steps to create a virtual switch with a VMotion-capable VMkernel port: 1. Add a new switch that includes a VMkernel port, as shown in Figure 9.26.
Figure 9.26 A VMotion enabled VMkernel port is required to perform a hot migration of a virtual machine.
2. Choose the network adapter that is connected to the VMotion network, as shown in Figure 9.27.
Figure 9.27 VMotion requires a virtual switch associated to a physical network adapter, preferably on a dedicated physical network.
3. Enable the Use This Port Group for VMotion option and assign an IP address appropriate for the VMotion network, as shown in Figure 9.28.
Figure 9.28 The vSwitch with the VMkernel port group for VMotion must be VMotion capable.
4. Click Finish. Add a default gateway if needed, as shown in Figures 9.29 and 9.30.
Figure 9.29 Finish the VMkernel port configuration to allow VMotion migrations.
Figure 9.30 A default gateway can be created for the VMkernel port if one is required. VMkernel ports with VMotion enabled should not require a default getaway.
If the VMotion network is nonroutable, leave the default gateway blank or simply use the default gateway assigned for the Service Console, as shown in Figure 9.31.
Figure 9.31 VMotion networks without a router do not need a default or the same default gateway as the Service Console can be entered.
A successful VMotion migration between two hosts relies on all of the following conditions being met:
? Both the source and destination hosts must be configured with identical virtual switches that have VMkernel port groups. The names of the switches must be the same as shown in Figure 9.32.
Figure 9.32 The two hosts involved in the VMotion migration must have similarly configured VMotion enabled virtual switches.
? All port groups to which the virtual machine being migrated is attached must exist on both ESX hosts. Port group naming is case sensitive, so create identical port groups on each host and make sure they plug into the same physical subnets or VLANs. A virtual switch named Production is not the same as a virtual switch named PRODUCTION. Remember that to prevent downtime the virtual machine is not going to change its network address as it is moved. The virtual machine will retain its MAC address and IP address so clients connected to it don't have to resolve any new information to reconnect.
? Processors in both hosts must be compatible. When a virtual machine is transferred between hosts, the virtual machine has already detected the type of processor it is running on when it booted. Since the virtual machine is not rebooted during a VMotion, the guest assumes the CPU instruction set on the target host is the same as on the source host. We can get away with slightly dissimilar processors, but in general the processors in two hosts that perform VMotion must meet the following requirements:
? CPUs must be from the same vendor (Intel or AMD).
? CPUs must be from the same CPU family (PIII, P4, Opteron).
? CPUs must support the same features, such as the presence of SSE2, SSE3, and SSE4, and NX or XD (see the sidebar, “Processor Instruction”).
? For 64-bit virtual machines, CPUs must have virtualization technology enabled (Intel VT or AMD-v).
Processor instruction
SSE2 (Streaming SIMD Extensions 2) was an enhancement to the original MMX instruction set found in the PIII processor. The enhancement was targeted at the floating-point calculation capabilities of the processor by providing 144 new instructions. SSE3 instruction sets are an enhancement to the SSE2 standard targeted at multimedia and graphics applications. The new SSE4 extensions target both the graphics and application server.
AMD's XD (eXecute Disable) and Intel's NX (NoExecute) are features of processors that mark memory pages as data only, which prevents a virus from running executable code at that address. The operating system needs to be written to take advantage of this feature, and in general, versions of Windows starting with Windows 2003 SP1 and Windows XP SP2 support this CPU feature.
The latest processors from Intel and AMD have specialized support for virtualization. The AMD-V and Intel Virtualization Technology (VT) must be enabled in the BIOS in order to create 64-bit virtual machines.
VMware includes a utility named cupid.iso.gz in the images subdirectory of the ESX Server installation CD. This tool can test a server to see what CPU features the host processors have. To perform the test, unzip it and make a bootable CD, then boot each ESX host from the cupid CD and compare the output. If they match, then VMotion is CPU compatible. If they don't match, then you need to determine what doesn't match.
On a per-virtual machine basis, you'll find a setting that tells the virtual machine to show or mask the NX/XD bit in the host CPU. Masking the NX/XD bit from the virtual machine tells the virtual machine that there's no NX/XD bit present. This is useful if you have two otherwise compatible hosts with an NX/XD bit mismatch. If the virtual machine doesn't know there's an NX or XD bit on one of the hosts, it won't care if the target host has or doesn't have that bit if you migrate that virtual machine using VMotion. The greatest VMotion compatibility is achieved by masking the NX/XD bit. If the NX/XD bit is exposed to the virtual machine, as shown in Figure 9.33, the BIOS setting for NX/XD must match on both the source and destination ESX Server host.
What happens if you have SSE3 features on one host and not on the other? For mismatched SSE3 and SSE4 processors, you can change the masking by clicking the Advanced button, shown in Figure 9.33, and entering the CPU parameters you wish to mask, as shown in Figure 9.34.
Some administrators might recognize that this is a tedious task if you already have dozens of virtual machines built. The setting is changed on each virtual machine. However, if you know you have mismatched NX/XD bits or SSE3/SSE4 masks, you can change your template virtual machine and any virtual machine deployed from that template will also have the same setting.
Figure 9.33 Masking the NX/XD bit on a virtual machine
Figure 9.34 Masking SSE3 extensions for an Intel CPU
In addition to the VMotion requirements for the hosts involved, there are requirements that must be met by the virtual machine to be migrated:
? The virtual machine must not be connected to any device physically available to only one ESX host. This includes disk storage, CD-ROMs, floppy drives, serial ports, or parallel ports. If the virtual machine to be migrated has one of these mappings, simply clear the Connected check box beside the offending device, as shown in Figure 9.35.
Figure 9.35 Clear the Connected box for any locally mapped device prior to migrating with VMotion.
? The virtual machine must not be connected to an internal-only switch.
? The virtual machine must not have its CPU affinity set to a specific CPU.
? The virtual machine must not have a RAW disk mapping as part of a Microsoft Cluster Services (MSCS) configuration.
? The virtual machine must have all disk, configuration, log, and nonvolatile random access memory (NVRAM) files stored on a volume visible to both the source and the destination ESX Server host.
If you start a VMotion migration and VirtualCenter finds an issue that is considered a violation of the VMotion compatibility rules, you will see an error message. In some cases, a warning, not an error, will be issued. In the case of a warning, the VMotion migration will still succeed. For instance, if you have cleared the check box on the host-attached floppy drive, VirtualCenter will tell you there is a mapping to a host-only device that is not active. You'll see a prompt asking if the migration should take place anyway.
VMware states that you need a gigabit network card for VMotion; however, it does not have to be dedicated to VMotion. When you're designing the ESX Server host, dedicate a network adapter to VMotion if possible. You thus reduce the contention on the VMotion network, and the VMotion process can happen in a fast and efficient manner.
To perform a VMotion migration of a virtual machine:
1. Select a powered-on virtual machine in your inventory, right-click the virtual machine, and select Migrate, as shown in Figure 9.36.
Figure 9.36 Starting the VMotion process
2. Choose the target host, as shown in Figure 9.37.
Figure 9.37 Choose the target host.
3. Choose the target resource pool (or cluster). Most of the time the same resource pool (or cluster) that the virtual machine currently resides in will suffice. Choosing a different resource pool might change that virtual machine's priority access to resources, as shown in Figure 9.38.
Figure 9.38 Choose a target resource pool for the virtual machine being migrated.
4. Select the priority that the VMotion migration needs to proceed with. Be aware that choosing high priority will cause CPU stress on the hosts involved in the migration, as described in the option shown in Figure 9.39.
Figure 9.39 Choosing a priority level for the migration
5. Click Finish once the validation has concluded and you have reviewed the information on the summary screen, as shown in Figure 9.40.
6. The virtual machine should start to migrate. Often, the process will pause at about 10% in the progress dialog box, and then again at 90%. The 10% pause occurs while the hosts in question establish communications and gather the information for the pages in memory to be migrated; the 90% pause occurs when the source virtual machine is quiesced and the dirty memory pages are fetched from the source host, as shown in Figure 9.41.
Figure 9.40 Click Finish to start the actual migration.
VMotion is an invaluable tool for virtual administrators, and certainly the feature that put ESX Server on the map. But VMotion, in this latest version of ESX Server, has evolved into more than just a simple tool for moving virtual machines. VMotion is the backbone for the new Distributed Resource Scheduler (DRS) feature that can be enabled on ESX Server clusters. Before we get to the details of DRS, you need to understand clusters.
Figure 9.41 Progress of a VMotion migration
Оглавление книги
