San Francisco

dave spink toolset




VM INFO:

PARTS SCSI-2 VAAI VDI
VMTOOLS ESX HBA


PARTS

A summary of VMware components.

  1. ESX Server - The hypervisor layer 1.
  2. Virtual Machine File System (VMFS)- A clustered file system for virtual machines.
  3. VMotion - Enables the live migration between physical servers with zero downtime.
  4. High Availability - In the event of server failure, VMs are automatically restarted on other production servers.

What Files Make Up a Virtual Machine?

  1. vmware.log - Keeps a log of key VMware Workstation activity.
  2. vmname.nvram - Stores the state of the virtual machine's BIOS.
  3. vmname.vmdk - This is a virtual disk file, contents of the virtual hard drive.

Note, the VMDK file will always be aligned with a block from NFS file system (at least from a Oracle Storage Appliance). However, the Guest OS must also be aligned. For example, modern versions of Windows use a partiton offset of 1MB, which guarantees aligned IO for the Guest.



SCSI-2

VMware versions lower than 4.0 only use SCSI-2 for communication and reservations. Even if an application issues a SCSI-3 reserve, it will convert it to a SCSI-2 reserve before sending it to storage. SCSI-2 reserves only allow the machine that implemented it to release the reserve, and in certain failure conditions mean that that machine must reboot to release a reserve.

SCSI-3 adds functionality to reserves that help greatly in clustered environments. A reserve can apply to a cluster rather than only to a single machine. It enables clustered file systems (e.g. in Oracle RAC) to work and also allows a cluster member to do a SCSI release on a reserve that was created by a cluster partner.

The SCSI reservations used by VM are not the same as SCSI-3 PER reservations used by Oracle RAC; and therefore this attribute is not required. ESX clusters do use SCSI Persistent Reserves, to place temporary, short term, locks on devices while updating its meta data. It's not the same thing as a SCSI-3 PER bit/attribute 'keys'.



VAAI

vStorage APIs for Array Integration (VAAI)- allows the ESX server to directly address VAAI-enabled storage arrays. The initial release of VAAI adds three features (see below), the initial VAAI release was for block-based storage only.

  1. Full Copy: This enables the storage array to copy data within the array. Hence, the ESX server does not read and then write the data.
  2. Block Zero: This brings hardware-enabled acceleration to common tasks.
  3. Hardware Assisted Locking: This improves the locking controls on VMFS allowing greatly improved performance.

Full Copy
Without VAAI to create a virtual machine from a 5GB template, the ESX server read the whole template from storage, and then write it back to storage; hence 10GB of I/O. With VAAI the ESX server sends an instruction that says "copy that template to the following new name", the array creates the copy and sends the ESX server back an acknowledgement when the copy is finished. The total data transfer is just the instruction and the acknowledgement. The difference is even more dramatic with Storage vMotion. The array sends an instruction to migrate the data (say 300GB), the array moves the data internally within the array and occasionally sends status updates to the ESX server. Tests have shown that creation of VMs and Storage vMotion is up to ten time faster.

Block Zero
Without VAAI, if the ESX server needed to write the same block 10 times, it would send 10 identical blocks to be written. With VAAI, it says "take this block and write it 10 times".

Hardware Assisted Locking
With multiple VMs on the same LUN you need to ensure a host doesn't attempt to write to the same block at the same time. Without VAAI, vSphere does this for the VMFS volume by locking the entire volume while any ESX server is writing to it. If you have a large number of VMs on the same volume locking can start to cause problems. VAAI changes this dramatically. With Hardware Assisted Locking, the ESX server will lock only the block(s) it's actually writing to, not the entire volume. EMC tested this by loading 300 VMs onto the datastore, and attempted to boot all of them simultaneously. It took 58 minutes to bring all 300 VMs up and online. In a repeat of the same test, this time with VAAI's Hardware Assisted Locking enabled, it took 17 minutes to bring all 300VMs up and online, plus 50% less I/O queuing.



VDI

Virtual Desktop Infrastructure is like thin-client computing such as Citrix or Terminal Services. VDI provides full access to a virtual machine and each virtual desktop is mapped to a single user. Here is an outline of steps needed to use VDI:

  1. Create a virtual machine on ESX Server
  2. Install a VDI Connection Broker (Citrix, ChipPC) - this determines which Remote Desktop Host a user is assigned to.
  3. Install a desktop operating system on that VM, such as Windows XP or Windows Vista
  4. Install desktop applications on the VM
  5. Allow remote access to that virtual desktop system via RDP, VNC, or others.


VMTOOLS

Installing VMware tools in the GuestOS modifies the scsi disk timeout to roughly 180 seconds. For example, in Linux VMs, VMwareTools adds /etc/udev/rules.d/99-vmware-scsi-udev.rules which has the following entries.

# Redhat systems
ACTION=="add", BUS=="scsi", SYSFS{vendor}=="VMware, " , SYSFS{model}=="VMware Virtual S",   RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'"

This causes the following in /sys/block/sda/device (on my example VM). It makes similar adjustments to the Registry for Windows VMs.

[root@oel1 device]# pwd
/sys/block/sda/device
[root@oel1 device]# cat timeout
180


ESX HBA

On ESX server you should see a clariion on the same sp's down both vmhba's...one "on" and one "standby" based on who owns the lun. Like this:

FC 23:0.0 10000000c964ed18<->5006016239a016d4 vmhba2:0:29 Standby  preferred
FC 23:0.0 10000000c964ed18<->5006016a39a016d4 vmhba2:1:29 On active
FC 19:0.0 10000000c964d25c<->5006016b39a016d4 vmhba1:0:29 On
FC 19:0.0 10000000c964d25c<->5006016339a016d4 vmhba1:1:29 Standby

When we had an issue with 10000000c964d25c, hence we block port.

FC 23:0.0 10000000c964ed18<->5006016239a016d4 vmhba2:0:29 Standby  preferred
FC 23:0.0 10000000c964ed18<->5006016a39a016d4 vmhba2:1:29 On active
FC 19:0.0 10000000c964d25c<->5006016b39a016d4 vmhba1:0:29 Standby
FC 19:0.0 10000000c964d25c<->5006016339a016d4 vmhba1:1:29 Standby

After couple of minutes it came back to normal.

FC 23:0.0 10000000c964ed18<->5006016239a016d4 vmhba2:0:29 Standby  preferred
FC 23:0.0 10000000c964ed18<->5006016a39a016d4 vmhba2:1:29 On active
FC 19:0.0 10000000c964d25c<->5006016b39a016d4 vmhba1:0:29 On
FC 19:0.0 10000000c964d25c<->5006016339a016d4 vmhba1:1:29 Standby