I’ve always felt a bit “iffy” about the use of the term “Advanced”, but when you scratching around for some sort of word for a loose collection of items that sometimes is what we lazily turn to. Invariably, we normally mean is actually just some more information, more often as not what really mean is “obscure configurations or settings that not everyone uses”. Because in reality often what’s been served up isn’t actually “advanced” or “difficult”, but just more information which you may or may not find useful.

So now I’ve got that big fat disclaimer out of the way, let me tell you what this post is all about. It’s a biggie, and none of the individual parts are related to it each other. So this post documents

• Adding additional SCSI controllers, specifically the Paravirtual SCSI Controller – which may (or may not) improve performance…
• Explaining Different Virtual Disk Types – here I try my best to explain the difference between between thin/thick and implications of using them on different physical storage types…
• Configuring Virtual Disks Modes – This covers persistent and independent modes
• Converting from Thin-to-Thick Disk – This covers the “inflate” feature, which really (as far I can tell isn’t really a conversion of the disk itself…)
• Converting from Thick-To-Think Disk – by using Storage vMotion…
• Checking VMware Tools is up to date – by using Quick Filters in the Web Client
• Windows XP Installations – Okay, obscure. But covers using SCSI controller drivers on a .flp file. I guess I should be promoting the use of application virtualization with ThinApp. But I reckon people being what they are will carrying on using WindowsXP natively for some applications that for whatever reason can’t be captured and streamed into Window7/8
• Using Static MAC Addresses – As you might know vCenter automagically generates MAC address for every machine and makes it unique. Occasionally, software vendors license by MAC address, so often its better to set this using a range provided by VMware.
• Converting a Physical Machine to a Virtual Machine – This covers the VMware Converter Stand-alone utility – which can convert not just physical machine, but whole host of other sources…

Adding SCSI Controllers & Using Different SCSI Controllers

It’s beens shown via testing that for disk intensive VMs, placing the data virtual disks on secondary SCSI controller improves throughput. However, in most cases the administrator is better off looking for other factors to increase disk performance such as:

• Relocate to a datastore with more spindles
• Ensure that VAAI is enabled on the Storage Array
• Enable a caching layer to reduce reads
• Adopt a SSD enabled R/W model

Most VMs use the same SCSI Controller that is selected to boot the OS partition. This normally selected on the basis that the Guest Operating System DVD .ISO possess a native driver that allows the OS install to continue. VMware does support its own Paravirtual SCSI Controller, this has been shown in certain circumstances to improve performance. Starting with vSphere 5.5, VMware introduced a AHCI SATA controller – which increases the number of devices configured to the controller . Arbitrarily, changing the controller type that holds the boot disk can cause problems if VMware Tools has not been installed (the Paravirtual SCSI Controller requires a driver), and adding additional controllers of multiple types can require editing the VMs BIOS settings to indicate which controller is the default boot device. In the past there have been compatibility restrictions surround using the Paravirtual SCSI Controller, at the moment the only restriction listed in official documentation is an incompatibility with Microsoft Failover Clustering.

Given the steps required to introduce the Paravirtual SCSI controller you might want to limit its use to special cases where maximum disk throughput cannot be increased by other means. It’s also highly recommended to backup the VM or snapshot so if something goes wrong in the configuration you have reset option at your disposal.

There’s really two options to using the Paravirtual – both involve adding it as second controller to trigger the activation and install of the VMware Tools driver. After that its possible to configure the data drives to be on SCSI1, and the boot disk on SCSI0 which would continue to use the default controller selected when the VM is created. Alternatively, its possible to change the SCSI Controller type of SCSI0 to be Paravirtual SCSI.

1. Before beginning confirm that VMware Tools has been installed to the VM, then Power down the VM, and then Edit Settings of the VM

2. Using the New Device list, select SCSI Controller, and click the Add button

3. Expand the >New SCSI Controller, and from the Change Type list, select VMware Paravirtual and Click OK

Note: BUS Sharing is used in certain clustering scenarios where a cluster software or service is being used inside a VM.

4. Next, Power on the VM. Launch a Console to the VM, and once logged in use Windows Device Manager to confirm the VMware Paravirtual Controller appears under Storage Controllers

The Paravirtual SCSI Controller should now be working for SCSI1, and additional virtual disks for storage maybe added or transferred to it.

5. Optionally, shutdown the VM, and Edit Settings and Change Type to VMware Paravirtual. Notice the warning about this causing the VM to potential not boot correctly.

Explaining Different Virtual Disk Types

From the UI the Web Client exposes three virtual disk types:

1. Thick Provisioned Lazy Zeroed
2. Thick Provisioned Eager Zeroed
3. Thin Provisioned

All three types are only available to deployments that leverage the VMFS File System. Where NFS is used you will find that only Thin Provisioning is available. Research by VMware has shown there is no significant difference in the formats from a performance perspective. Consult Performance Study of VMware Thin Provisioning for further details. The selection of one disk format over and other is dependent on a number of factors such as how much physical free space the target datastore possesses; how you monitor the storage and whether the environment is using VMFS or NFS as the storage protocol. For instance the discussion of different virtual disk types is largely of academic interest to environment based on NFS where only a thin provisioned virtual disk is available.

Thick Provisioned Lazy Zeroed

Acknowledgement: Image is kindly reproduced courtesy of Chad Sakac’s VirtualGeek blog

A Thick Provisioned Lazy Zeroed disk if defined as 500GB in size will consume 500GB of disk space on a physical datastore, despite the fact it might only contain 100GB of on-disk data. This disk type is fast to create, and guarantees that 500GB will be available – assuming the physical datastore itself is not thinly provisioned. If placed on a thinly provisioned physical datastore the focus is on monitoring the physical storage array’s management tools to track usage, and configuring alarms and alerts to ensure there is actual disk space. If the physical datastore is thickly provisioned then alarms and alerts in vCenter can be trusted to reflect the true amount of disk space. Thick virtual disks on thick physical datastores present the clearest consumption figures to the virtualization SysAdmin. However, they can be quite wasteful – as historically application/VM owners have demand more disk space than they use. The free space in the virtual disk is then “wasted” as it cannot be allocated elsewhere. This problem is not insignificant, and if not correctly managed can be an expensive approach. There are stories of people buying whole new storage arrays or new disk shelves due to this over-provisioning of disk capacity.

Thick Provisioned Eager Zeroed

A Thick Provisioned Eager Zeroed disk defined as 500GB in will consume 500GB of disk space even if placed on a physical datastore that has been thinly provisioned. During the disk creation zero’s a written through every block on the disk, in a process which is similar to a secure delete process. This ensures the disk is fully pre-allocated on the respective physical datastore. As such there is no benefit to using this format inconjunction with thinly provisioned physical datastores. This format is used specifically by the VMware Fault Tolerance (FT) feature. As such its much slower to provision the virtual disk in this format, and when enabling VMware FT time must be allocated to a disk conversion process if the disk is in the other two formats.

Thin Provision

Acknowledgement: Image is kindly reproduced courtesy of Chad Sakac’s VirtualGeek blog

A Thin Provision virtual if defined as 500GB in size will only consume the disk space that has been written to it. If a 500GB thin virtual disk contains 100GB of on-disk data, then it will only consume 100GB of disks space on the physical datastore. Thin virtual disks are fast to create, and space efficient. Thin provisioning a virtual disk allows for a degree of oversubscription where more virtual disk space is allocated than is physically present on the datastore. The danger of thin provisioning can come with insufficient monitoring, where there is a sudden an unexpected increase in disk consumption. This can easily happen in Test/Dev environments where use of tools like IOMeter to generate disk activity can lead to partitions becoming full very quickly. However, in production environments where increases in disks consumption are more linear and gradual, effective monitoring and alarm thresholds can be configured to prevent outages created by out-of-space conditions. What’s not recommended in production/enterprise environments is doubling down on thin provisioning – by using thin virtual disks on thinly provisioned datastores/LUNs/Volumes. This can lead to underlying disk consumption being obscured, and outages. Generally, people will recommend thin-virtual disks, on thickly provisioned data stores OR thick virtual disks, on thinly provisioned datastores. This compromise offers the best underlying consumption results, but minimises the potential risk of outages. In homelab environments using thin-on-thin is consider less risky as the disk space consumed can be relatively small.

Finally, one issue affects VMs based on thinly provisioned disks which is that of recouping free space created by deleting files. This caused by the fact that most Guest Operating Systems do not delete files from the disk, but mark them for deletion. This can cause a skewing of statistics – where the Guest OSes indicates there is free space, but vCenter reports that free space different or a much smaller amounts. Many people would consider this not something to worry – as eventually the freed up space will be written. Prior to vSphere 5.5 there was a work-around which was to use Storage VMotion to move a VM from one datastore to another – this process would ensure that blocks that are empty or contain data that has been marked for deletion would not be copied. However, changes in the implementation of VAAI now means this work-around does not work in all cases. Duncan Epping has blog post that outlines this change.

The Storage Usage gauge on a thinly provisioned VM should report the actual disk space consume as compared to the virtual disk size. In this case 4.96GB of space is being used from a thinly provisioned 32GB virtual disk.

In this case a Windows C: drive was filled to capacity, and then the redundant data was deleted. This freed up almost 30GB of free space within the Windows with 8GB being in use, but the vSphere Web Client reported the disk was using almost all of its capacity.

Note: Storage Usage includes all the data used by the VM including such items as its VMkernel Swap File. As the VM has been allocated 4GB of RAM, by default it has 4GB swap file. This explains why Storage Usage is greater than the virtual disk size.

To reset the disk counters in the Web Client, the VM was Storage Migrated from its VMFS volume to an NFS volume. This triggers the use of non-VAAI enabled copy mechanism, which forces just blocks of occupied data to be copied. Once completed the VM was Storage Migrated back to the source VMFS.

Configuring Virtual Disks Modes

By default all virtual disks are set to be a “Dependent” disk mode:

Disk Modes largely control how data is written to the virtual disk, and how snapshots function. With Dependent Mode the virtual disk is available to be included in the snapshot. If snapshots are not present then data is written to the virtual disk, and held permanently. With Independent – Persistent Mode, the virtual disk is excluded from the snapshot process, and no delta virtual disk is allowed. It is possible for one virtual disk to be in “Dependent” mode and another to be “Independent” mode within the same VM and still use snapshots. With Independent – Non-Persistent Mode, when the VM is powered on the virtual disk automatically is allocated a delta virtual disk, when ever the VM is powered off, the delta virtual disk is discarded, and the VM is reset back to its initial state.

Changing of disk modes in production environments are rare – as changing the disk mode from Dependent to Independent will stop most VM backup systems that require the ability to snapshot a VM in order to back it up. However, there maybe scenarios where a virtual disk does not require backing up because it contains mainly non-changing read-only data or alternatively VMs used in a kiosk style environment where nightly reset maybe initiated by merely powering down and powering on the VM. With that said, the same result could be achieved by taking a snapshot, and then reverting it.

Setting a disk with Independent – Persistent Mode will prevent the administrator from taking a manual snapshot of the VM whilst it is powered on – as this disables the ability to snapshot the contents of memory – as can be seen below

In this case if the administrator wanted to snapshot the VM, it would have to be powered down first.

Converting from Thin-to-Thick Disk

A VM can be converted from Thin to Thick (Lazy Zeroed) disk using the “inflate” option within the datastore where its .VMDK files are located. The process can be carried whilst the VM is powered off to be successful. Merely, locate the VM in the datastore, and then locate the virtual disk, and right-click to choose the “Inflate” option in the menu. To be accurate this process is not a conversion as such, it takes the thin virtual disk and inflates to its maximum size.

Note: This inflates the thin virtual disk to its maximum size, but the Web Client will still report its type as “thin” in the interface, so technically its not changing the format specifically.

Converting from Thick-To-Think Disk

Unlike Thin to Thick conversions there is no “easy” way to trigger the conversion of the virtual disk from Thick to Thin. However, one of the easiest method of carrying out the switch from one format to another appears when a VM is relocated from one datastore to another during the process of Storage Migration – the process such as it is can be carried whilst the VM is powered on. All the administrator has to do is right-click the VM, and choose Migrate – and select Change Datastore in the wizard. At the point of selecting a different datastore the Administrator can opt to change the virtual disk format like so:

Checking VMware Tools is up to date

Checking whether the VMware Tools is running and up to date is perhaps best done using a PowerCLI command. However, it is possible to change the views in the Web Client to show additional information about the VM including its IP address and VMware Tools status. A flat list of VMs can be viewed in the properties of a datacenter, cluster or host under the Related Objects, and VMs column

By default the views show simple information such as the Name, State, Status and so on of the VM. These columns headings can be supplemented with additional headings, by right-clicking near the headings, and the Show/Hide Columns option

From the field selector, you can include such attributes as IP Address, VMware Tools Version, VMware Tools Running

These fields can then be sorted to show situations where VMware Tools has simply not being installed or is in need of an upgrade.

Finally, you can use a combination of “Quick Filters” and ordinary text based filters to exclude VMs from the list that you do not need to see

Windows XP Installations

At the time of writing Windows XP has recently reached a product support milestone, and is no longer supported by Microsoft. There are plenty of tools that would allow you to capture the installation of software to Windows XP, and run that on a new client OS such as Windows 7 or Windows 7. This is referred to as “Application Virtualization” were a shim or runtime is used to isolate the VM the difference found in the Operating System. However, there maybe cases where the organization cannot or will not migrate away from WindowsXP and legacy applications are required to run within its native environment.

Windows XP can be installed natively to an IDE virtual disk, and this common with older legacy client OSes such as Windows Vista, Me, 98 and 95 as frequently these OSes did not ship with very good support for SCSI controllers. IDE based virtual disks suffer from the limitation of not being expandable – so if you do use IDE ensure you supply the OS disk with plenty of free diskspace for both the OS and applications. Alternatively, you can use the LSI Logic Controller drivers from the LSI Logic website, or use BusLogic with a .flp file supplied by VMware.

The LSI Logic driver can be found on their site by going to http://www.lsilogic.com/cm/DownloadSearch.do and searching for a driver for the LSI20320-R controller. Once download its possible to create a floppy disk image using tools such as WinImage. Some community members have already completed this process had uploaded their LSI Logic .flp floppy images ready to download. Alternatively, the BusLogic Controller can be download from VMware’s website at http://download3.vmware.com/software/vmscsi-1.2.0.4.flp.

Once the .flp file is created it can be uploaded to a datastore and connected along side the Windows XP CD-ROM .iso…

You may wish to include a boot delay – to allow enough time to power on the VM, open and console and capture the point where pressing [F6] allows you supply different mass storage driver. Boot options under VM Options allows you to configure a boot delay in milliseconds, and can be useful if you want to access the VMs BIOS settings or send keystrokes to the VM to control the POST process such as indicating you want to boot from a recovery CD or PXE boot.

This should mean on first power on, the administrator should see the VMware BIOS screen. The administrator can use the [ESC] key to access a boot menu

From there they can force the WinXP VM to boot to the CD-ROM (rather than from the hard disk or floppy disk)

And this will allow the administrator to use the [F6] menu to supply the LSI Logic or BusLogic Driver

Using Static MAC Addresses

By default vCenter maintains a pool of MAC addresses that is large enough accommodate the demands of the enterprise. The MAC address is assigned from this pool, and not reused again. Under normal operating circumstances the MAC address assigned to the pool will not change. There are some situations where the MAC address can be reset. For instance, a VM “removed” from the Inventory on one VMware ESX host, and “Registered” to the Inventory on a different ESX host – this will prompt a question about how to manage the UUID value. If the UUID value is changed, then this will result in a new MAC address assignment.

The screen grabs below illustrate this scanerio

Note: Here the VM is powered down, and removed from the inventory

Note: Here the datastore is browsed, the VMs .VMX file located and right-click allows for the VM to be re-registered

Note: Here the VM is powered on using a different VMware ESXi host triggering the question.

If the administrator selected “I copied it” a new UUID and MAC address would be created. If the administrator selected “I moved it” then the UUID and MAC address would NOT  be changed.

Its rare for this to happen, and it only occurs under particular circumstances such as the one described. However, there are cases that administrators prefer not to use this dynamic auto-assignment of the MAC address. A good example of this would be in situations where the application software or services installed to the OS are licensed by MAC address. In this case, some administrator prefer to assign a static IP MAC address, and then transmit that the ISV before the generation of any license keys or files. This ensure if they ever need to rebuild or re-install the VM, OS or software they guarantee the MAC address will work with the license key.

VMware has assigned range of valid MAC addresses for this purposes. The starting range starting at 00:50:56:XX:YY:ZZ and ending at 00:50:56:3F:FF:FF. In this case XX is a valid hex number between 00 and 3F and YY and ZZ are valid hex numbers between 00 and FF. The value for XX must not be greater than 3F in order to avoid conflict with MAC addresses that are generated by the VMware Workstation and VMware GSX Server products. Thus the maximum value for a manually generated MAC address is 00:50:56:3F:FF:FF.

To configure a static MAC address, powered down the VM, and Edit Settings. Next expand the NIC interface(s), and switch from Automatic to Static MAC address format, and type in the MAC Address:

Converting a Physical Machine to a Virtual Machine

VMware provides for free software called VMware Convertor – and it can be used to carry out conversion of VM from one virtual platform to another, and for converting physical machines to virtual machines. This includes:

• Physical Machines
• VMs in other vSphere/vCenter implementation
• VMware Workstation/VMware Fusion
• Symantec LiveState Recovery Images
• Acronis True Image Backup
• Microsoft Windows Hyper-V VMs
• Microsoft VirtualPC
• Parallels Virtualization Products

It’s stand-alone package that can be installed into a Windows system and includes wizards that can guide you through the conversion process. Although the conversion can be carried out whilst the target system in powered on. To carry out the conversion the target:

• On the network
• Accessible with Full administrator rights
• Not blocked by a firewall

These can make conversion of VMware Workstation/Fusion/ and Microsoft Virtual-PC tricky as many of these hosted virtualization platforms utilize bridging or NAT technologies that do not allow inbound access by default.

The installation of VMware Convertor is pretty standard affair of selecting where the binaries are located – and indicating if you want a “Local Installation” or “Client-Server” installation. This client server option is used in situations where the agent (aka client) cannot be install remotely across the network.

1. Once the software has been installed to your management machine, VMware Convertor can be loaded. The Convert Machine button allows you to select type of conversion. Using either an IP address or FQDN specify the source VMs details together with a username and password

2. After a short while a pop-up will appear asking how to handle the VMware Convertor Agent which installed remotely – it give the administrator the option of uninstalling the Agent after the conversion process completes, or to manually remove it after the process is over

3. Next the Administrator provides the destination details, in this case this the FQDN of the vCenter Server together with the administrator name and password

4. Next the wizard will ask the administrator to set the VM name and location in the inventory. The VM name is initiailly populated with the hostname/NETBIO name of the source VM

5. Next the administrator decides where upon which host/cluster/datastore the VM will reside

6. The options part of the wizard allows for substantial changes to be made to the VM, such as increasing or decreasing the size of the virtual disk, allocation of CPU/Memory – as well as being able to patch the VM into the correct network location.