Creating and Modifying Virtual Machines

Introduction to Virtual Machines

Version: vSphere 5.5

It might seem odd at this stage to have section introducing virtual machines. Ideally, this something you already know something about – or else why would you be here? But its perhaps worthwhile taking a little history lesson about the development of the virtual machine since VMware became to gain mass recognition in the 2003/4 period. Back then the hardware capabilities of the VM were more modest. The maximum number of vCPUs was just two, and the maximum amount of memory was just 3GB. On the virtual disk side of the house, the VMDK maximum size was a merely 2TB. Fast forward to the current period the scale of the VM has increased massively – to the degree that the only barrier to virtualization is whether it is economic. Nowadays, a VM can have up to 64 vCPUs, 1TB of RAM, and 62TB virtual disks. Advancements have also introduced the ability to give the VM direct access to hardware, where IO performance demands require it.

Upload Operating System ISOs to a Datastore (Web Client)

Perhaps the most common way of installing a Guest Operating System to a VM is using the original CD-ROM/DVD .iso that is used to distribute it. Being able to download .ISO images of Operating Systems has become the norm in the period of high bandwidth internet, and certainly beats having to order physical media deliveries. A VM can optionally boot to PXE, and therefore other OS deployment tools are available such as the Ultimate Deployment Appliance (UDA), Windows Deployment Services and third-party tools. However, it remains the case that most virtualization admins use a DVD .iso

1. In the Web Client browse to >>Storage, Select the datastore, and Manage tab

2. Select the File column

3. Click the Datatore icon with the “up arrow” to upload a file

Screen Shot 2014-04-08 at 12.47.11.png

4. Browse to the .ISO image and click OK

Note: You can watch the progress of the upload from the bottom of the Web Client datastore view

Screen Shot 2014-04-08 at 12.51.10.png

Creating Virtual Machines (Web Client)

Creating a virtual machine is as simple as following a wizard and answering the configuration options. This requires knowing what resources your VM will need for its applications. This is difficult to know upfront, so most virtualization administrator initially specify quite small resources allocations initially. This is because its always easier to grant more resources if they are needed, than try to reclaim unused resources from a disgruntled application owner. Application owners being what they are will always demand more resources than they will potentially need under normal conditions. Often they are following guidelines from the software vendor or from past experience in the physical world – where the specification was excessive and limited by the inflexibility of physical servers. Some virtualization administrators build VMs based on different sizes – small, medium, large, x-large with progressively more and more vCPU and memory allocated. At the very least the first VM with a given OS is likely to act as the template or “Gold Master” for all subsequent VMs made of that type.

Creating a Virtual Machine

1. The New Virtual Machine wizard can be invoked in almost any part of the vCenter inventory. A logical place to begin might be either which Host/Cluster you wish to run on, or in which VM folder you would like it reside. A right-click will expose the New Virtual Machine option in the menu like so:

Screen Shot 2014-04-08 at 13.08.53.png

2. The New Virtual Machine wizard exposes a number of different ways of creating a new VM including – however, for them to all to be available you must initially Create a new virtual machine to enjoy the benefits of cloning and templates.

Screen Shot 2014-04-08 at 13.18.28.png

3. Next type in a name for the VM, as this is going to be our “source” VM for templates, we have opted to use a generic name “Win2012R2”. Select a VM folder location for the VM.

Screen Shot 2014-04-08 at 13.21.23.png

Note: The VM’s name can be 80 characters long and must be unique to its folder location. Many virtualization administrator opt to use the same name as the hostname or NETBIOS name. If this is the case for you, remember that NETBIOS names are limited 15 characters.

4. Next select a Host/Cluster/Resource Pool for the location of the VM. A compatibility check will take place to confirm that the Host/Cluster/Resource Pool has the neccessary features to allow the VM to function

Screen Shot 2014-04-08 at 13.25.50.png

Note: Clusters and Resource Pools will be covered later. They are included here for virtualization admins working in environments where clusters and resource pools have already been created.

5. Next select a datastore location for the VM. In this case we selected the datastore that will be used to hold our current templates.

Screen Shot 2014-04-08 at 13.37.27.png

Note: Storage Policies are way of classifying storage by different capabilities, and assists the administrator select the right type of storage for the VM’s needs. These policies will be covered later.

6. Next select a compatibility level for the VM. Virtual Machine come with hardware or “compatibility levels” which define their functions. This often closely tied to the edition of VMware ESX that you are running. The most current level if 10 which is only available on VMware ESX 5.5 or higher. It is possible to run older editions of VMware ESX with vCenter 5.5, and as such you may need to select the right “compatibility level” to suit the generation of VMware ESX host software you are currently running.

Screen Shot 2014-04-08 at 13.45.11.png

7. Next select the Guest OS Family (Windows, Linux, Other), together with the version of OS within that family. VMware vSphere boast one of the largest array of guest operating systems, including ones not even supported by the vendors. This makes it a great choice for running legacy applications that cannot be ported to new operating systems. Setting the correct Family/OS type is important as this controls what type of “VMware Tools” is installed, and can also influence the defaults and settings made available to the VM.

Screen Shot 2014-04-08 at 13.49.08.png

8. The Customize Hardware page presents many, many options for greater changes. The most important/popular ones will be covered later. For now the focus should be on ensuring the that the right number of CPU, Disk Type and Network is correctly configured

Under >CPU select the right number of vCPUs for your workload

Expand >New Hard Disk – notice that the default creates a full-allocated “Thick Provision Lazy zeroed disk”. This means that 40GB virtual disk will take up 40GB of actual disk space despite there being only 7GB of actually data consumed. Thin Provisioned disks are much more space efficient. Although 40GB in size, the on disk penalty will be the actual amount of disk space consumed within the guest operating system. For more information and detail on different disk format consult this section about Explaining Different Virtual Disk Types and Converting Virtual Disk formats.

Screen Shot 2014-04-08 at 14.21.28.png

Expand >New Network – and select which portgroup/VLAN us wish to use, and change the Adapter Type to be VMXNET3. Many guest operating systems support different types of network adapter types. VMXNET3 is specific to VMware, and requires the “VMware Tools” package to be installed to Windows for it to work. It offers the best performance. The adapter types are there for backwards compatibility (VMXNET2) or general compatibility (e1000) or to grant the VM direct access to physical hardware (SR-IOV)

Screen Shot 2014-04-08 at 14.28.56.png

Note: Portgroups on Standard Switch present themselves as just text label

Screen Shot 2014-04-08 at 14.29.28.png

Note: Whereas portgroups on Distributed Switches present both the portgroup name, but also the Distributed Switch name. Optionally, its possible assign specific port number on the Distributed Switch rather than using methods that automatically allocate ports.

9. Next to >New CD-Rom Device, from the pull-down list select Datastore ISO and browse to the datastore that holds your .ISO images.

Screen Shot 2014-04-08 at 14.36.42.png

10. Next, ensure the CD-Rom Device is Connected and Connected at Power On

Screen Shot 2014-04-08 at 14.40.50.png

11. Finally click Next and Finish to complete the creation of the VM.

First Power on and Remote Console

At first power on the VM’s BIOS settings default to CD-ROM first, with subsequent power on’s this is placed a lower priority in the VM’s boot order. So as long as you attach a bootable DVD .ISO and ensure the CD-ROM Device is connected then – at first power on the VM should boot from the ISO.

1. Right-Click the VM, and select Power On

Screen Shot 2014-04-08 at 14.55.07.png

2. To open a Remote Console window on a VM, right-click and select Open Console or Launch Console from the VMs Summary tab.

Screen Shot 2014-04-08 at 15.16.04.png

Screen Shot 2014-04-08 at 15.36.57.png

This should launch a separate tab in your Web Browser showing the console of the VM. You can send the Control+Alt+Delete keystoke to the VM using the provided button, and toggle from Window to Full-Screen. The keystoke Ctrl+Alt can be used to release the keyboard and mouse focus from the VM, if you need to interact with your local desktop or move back to the Web Client. Despite this ILO/DRAC/RAC style access to the VM most administrator enabled SSH to allow administrative access to Linux VMs and Microsoft Remote Desktop Protocol for Windows VMs. In virtual desktop environments the PCoIP Protocol is enabled and the Horizon View client used to access the desktop for best performance and functionality.

Screen Shot 2014-04-08 at 15.38.52.png

From this point onwards the installation of the operating system happens as is without modification.

Installing VMware Tools (Windows)

Once the guest operating system has been installed the next step is to install a package called VMware Tools. This package adds drivers and additional software services to improve performance and allow for easier controls. These include being able to reboot the VM by sending a soft instruction to the operating system and a heartbeat service that will send alerts based on the VM’s state.

1. On the Summary Tab of the VM. The Web Client will alert that VMware Tools has yet to be installed, and offer a link to trigger the installation. This actually mounts DVD .ISO on the host to the VM.

Screen Shot 2014-04-08 at 19.48.51.png

2. In the subsequent pop-up window click the Mount button

Screen Shot 2014-04-08 at 19.57.55.png

3. If AutoPlay is enabled these should launch the installation. In the case of Windows 2012 R2, AutoPlay is not enabled by default – and you will need open the CD-ROM drive with file explorer to make it start.

Screen Shot 2014-04-08 at 20.06.46.png

4. Most virtualization administrators opt for a complete install. This can make the VM more portable between different virtualization platforms from VMware, it also means the VM is fully-featured for any scenario.

Screen Shot 2014-04-08 at 20.14.22.png

5. At the end of the install – the network should start because the VMXNET3 driver has been installed. You will also be required to reboot to ensure the drivers are all properly loaded. Subsequent upgrades of VMware Tools should not require a reboot. After a reboot the Summary tab should indicate the tools are running, and up to date – and should report information such as IP address and hostname.

Screen Shot 2014-04-08 at 20.30.32.png

Notice that the DVD .ISO used to install Windows 2012 R2 is still connected. It is good practise to disable the CD-ROM Device as this can decrease performance and cause warning and alerts in health check scripts and third-party tools. You can disconnect the device with the small icon next to it:

Screen Shot 2014-04-08 at 20.41.40.png

Installing VMware Tools (Linux)

Once the guest operating system has been installed the next step is to install a package called VMware Tools. This package adds drivers and additional software services to improve performance and allow for easier controls. These include being able to reboot the VM by sending a soft instruction to the operating system and a heartbeat service that will send alerts based on the VM’s state.

1. On the Summary Tab of the VM. The Web Client will alert that VMware Tools has yet to be installed, and offer a link to trigger the installation. This actually mounts DVD .ISO on the host to the VM.

Screen Shot 2014-04-08 at 19.48.51.png

2. In the subsequent pop-up window click the Mount button

Screen Shot 2014-04-08 at 19.57.55.png

3. In Linux this should mount the VMware Tools DVD ISO to a mounting mount – if not these command will allow the DVD .ISO to be accessible

mkdir /mnt/cdrom
mount /dev/cdrom /mnt/cdrom

4. The VMware Tools are stored in tar.gz and this can be copied to temporary location and extracted

cp VMwareTools-N.N.0-NNNNNN.tar.gz /tmp
cd /tmp
tar -zvxf  VMwareTools-N.N.0-NNNNNN.tar.gz 

This extracts the VMware Tools .tar.gz file to the /tmp/vmware-tools-distrib

5. Inside this directory is a Perl script called vmware-install.pl which will install the VMware Tools, and can be executed with ./vmware-install.pl. For the most part this utility asks for the default directories for the tools themselves.

6. Mid-way through the installation, /usr/bin/vmware-config-tools.pl script will execute, which allows the administrator to control how the tools function. This allows the control of whether the “VMware Sync” driver is installed which is used by many backup vendors, and is responsibility for sync the file system with the file system cache

Screen Shot 2014-04-08 at 21.44.35.png

7. A full installation will attempt to enable the “Shared Folder” feature – this option is only available to desktop style virtualization such as VMware Workstation and VMware Fusion. This feature is not supported in VMware ESX and does not need to be enabled. The same is true of the vmBlock feature.

Screen Shot 2014-04-08 at 21.48.23.png

8. VMware Tools can be configured to allow the automatic building and installation of kernel modules at boot that are not present.

Screen Shot 2014-04-08 at 21.49.56.png

9. If a Linux graphical front end is discovered, the administrator will prompted with questions about resolutions in use

Screen Shot 2014-04-08 at 21.51.36.png

10. At this stage all the core services and drivers will be started

Screen Shot 2014-04-08 at 21.52.27.png

As with the install of VMware Tools, you may well need to reboot Linux to get full-fuctionality from VMware Tools. But after the install subsequent upgrades should be seamless and not require a reboot. Again, you can confirm the status of VMware Tools the Summary tab of the VM.

Screen Shot 2014-04-08 at 22.36.48.png

Common Virtual Machine Settings (Web Client)

This section covers common virtual machine settings and options that every administrator should be aware of. This is by no means exhaustive – but it should be good starting point to learn about alternative configurations.

VMware Tools – Time Synchronisation and Updates

It’s common in most environments for VMs to receive time updates from the physical VMware ESXi host – which in turn is configured to an external NTP time source. Additionally, as user patch and maintain VMware ESX which can be done seamlessly without effecting VMs, its not unusual for VMware Tools to become out of date. Two settings on the properties of the VM can enable time synchronisation and also instruct the system to automatically update VMware Tools when ever a VM is powered on.

1. Select the VM in the inventory, in the Summary Tab select Edit Settings

2. Under the VM Options tab, expand >VMware Tools

3. Enable the options X Check and Upgrade VMware Tools before each power on and X Synchronize guest time with host

Screen Shot 2014-04-09 at 07.55.43.png

Managing Virtual Disks

It’s not uncommon for an administrator to want to increase the size of virtual disk and/or add additional disks to allow for the storage of application data. VMware vSphere has supported the hot-grow and hot-add of virtual disks for some years, and the process has become easier now that most guest operating system have the built-in tools to grow the file systems within the virtual disk. In the past third party partition tools such as Dell ExtPart would be need to grow the OS partition if it was running out of space for instance. Limits do still exist around this – not least that in Windows 2012 R2 all operating systems disks and partitions default to using MBR to enumerate the size of the disk, and an allocation unit size in NTFS that makes extending the disk OS partition disk difficult beyond 2TB limit. In most case this isn’t a practical limitation.

Increasing Virtual Disk Size

1. Edit Settings of the target VM

2. In the Virtual Hardware tab, increase the spinner for the virtual Hard Disk to the desired size

3. Click OK

Screen Shot 2014-04-09 at 08.07.58.png

Note: Increasing the size of a thinly provision disk is unlikely to create any immediate pressure on the amount of free space in the vSphere datastore – however, if the virtual disk is “thickly” provision then free space must be available to increase the virtual disk size.

4. In a guest operating system such as Windows 2012 R2, open Computer Management – and with right-click on the Disk Management node, select Rescan Disks – to make the operating system aware of the new disk size

Screen Shot 2014-04-09 at 08.13.15.png

5. Next, right-click the partition within the virtual disk and select Extend Volume

Screen Shot 2014-04-09 at 08.13.43.png

6. After the wizard has been completed the partition within the newly grown virtual disk will take up the new free space

Screen Shot 2014-04-09 at 08.15.18.png

Adding Additional Virtual Disks

Adding additional disks to an existing VM is merely a question editing the settings, specifying the size and location. Most of the work is conducted within the scope of the guest operating system.

1. Edit Settings of the target VM

2. In the Virtual Hardware tab, at the bottom of the dialog box, click the New Device —-Select—- list,

3. From the list select New Hard Disk, and then Click Add

Screen Shot 2014-04-09 at 08.38.30.png

4. Select the size of the disk, and whether it should be thinly provisioned or not and click OK

5. The new virtual Hard Disk should appear in the VM Hardware pane

Screen Shot 2014-04-09 at 08.41.27.png

Note: The adding of a thinly provision disk is unlikely to create any immediate pressure on the amount of free space in the vSphere datastore – however, if the virtual disk is “thickly” provision then free space must be available to increase the virtual disk size.

4. In a guest operating system such as Windows 2012 R2, open Computer Management. The new virtual Hard Disk should appear, right-click the disk and select Online.

Screen Shot 2014-04-09 at 08.42.38.png

5. Once online the disk will need “initialization” with Initialize Disk. Care must be taken when initialising the disk to use GPT to ensure the file system disk can be easily increased in size beyond 2TB boundaries

Screen Shot 2014-04-09 at 08.44.22.png

6. After the disk is initialised it can be formatted, again case must be taken to choose an appropriate Allocation Unit size for the disk. If the cluster size is left at low value you may struggle to increase the size of partition to the maximum addressable size.

Screen Shot 2014-04-09 at 08.49.50.png

Once these guest operating system steps have been completed, the newly added virtual Hard Disk will be ready for use

Screen Shot 2014-04-09 at 08.50.50.png

Adding Raw Device Mappings

Raw Device Mappings or RDMs are way of giving a VM “direct” access to a LUN/volume on an FC or iSCSI array. It’s is not the only way of achieving this configuration – for instance the guest operating system residing in the VM may indeed support an iSCSI initiator – and if appropriate configured (network route, IQN, Target IP). However, considering the VMware ESX host(s) may already configured for iSCSI this could be regarded as more complicated configuration. One the myths of virtualization is that RDMs deliver better performance – this maybe due to misinterpretation of the term “Raw”, where actually is what is implied is “native” access to the storage. With RDMs the SCSI calls begin in the guest operating system and are translated through the VMware ESX host – the performance difference is negligible, if not nil. More commonly RDMs are used:

  • To grant access to large volumes of existing data, where coping that data into a virtual disk is deemed unnecessary
  • In some guest operating system clustering scenarios
  • To allow for advanced controls over the SAN from the VM. Often referred to as a “control” LUN

Care should be taking in selecting the use of RDMs outside of these use case as it makes the VM less “portable”. For instance decommissioning an array, and using Storage Migration to move VMs to a new storage array is more complicated if RDMs are in use. Additionally, there are some technologies from VMware and third-parties that do not support the use of RDMs currently. For instance, VMware’s vCloud Director does not support the use of VMs with RDM within the Service Catalog. Finally, any LUN that is presented to the VM using RDMs should be masked/presented to ALL the VMware ESXi hosts within the cluster – failure to do so can stop features like VMotion and Distributed Resource Scheduler (DRS).

The process of adding an RDM creates a small “mapping” file with the .VMDK extension. This file is only a couple of kilobytes on disk, but reports the true size of the LUN/Volume on the array. RDMs come into modes – Physical and Virtual. The virtual mode allows for features normally only available to virtual disks such as snapshots.

1. Edit Settings of the target VM

2. In the Virtual Hardware tab, at the bottom of the dialog box, click the New Device —-Select—- list,

3. From the list select RDM Disk, and then Click Add

Screen Shot 2014-04-09 at 10.07.36.png

4. From the Select Target LUN pop-up dialog box, select the LUN that will be granted to the VM

Screen Shot 2014-04-09 at 10.15.52.png

5. Expand the >New Hard Disk, and select Virtual from the Compatibility Modes.

Screen Shot 2014-04-09 at 10.40.54.png

Caution: You should not include RDMs in VMs you intend to later convert into templates – as the RDM mapping would be included in that template.

Removing Virtual Disks

Caution: To remove a virtual disk, start with taking the disk “Offline” from the guest operating system, thus ensuring no changes are taking place in the file system prior to removal. Removing the virtual disk offers the choice of either just disconnecting it from the VM, or disconnecting and deleting the virtual disk in one operation. Deleting a virtual disk is non-reversible operation, and the only way to restore a deleted virtual disk is by using the backup vendor of your choice.

1. Edit Settings of the target VM

2. In the Virtual Hardware tab, locate the virtual Hard Disk you wish to remove, and click the grey remove X icon

Screen Shot 2014-04-09 at 10.51.02.png

3. After clicking the X icon, you will have the option to either remove the device, or remove the device and delete the virtual disk.

Screen Shot 2014-04-09 at 10.52.29.png

Adding Network Interfaces and other hardware

The VM does support other devices including:

  • Network Adapters
  • Additional CD-ROM/Floppy
  • Serial Port
  • Parallel Port
  • Host USB Device
  • SCSI Controller
  • SATA Controller
  • PCI Device

Whether VMs actually require these devices depend much on the circumstances and requirement of the guest operating system. For instance if you are running clustering software within the guest operating system its likely that additional network adapters will be need for the primary network, and the “heartbeat” network. In conventional, classical clustering the VM may well need an OS disk, Data Disk and Quorum Disk – and these secondary disks could require additional SCSI controllers as well as BUS setting to indicate there are shared with other nodes in the cluster. Typically, Virtual Storage Appliance (VSA) will typical require multiple disks and network cards and will ship with these device ready configured. Finally, the OS inside the VM may have specialist network functions such as being a firewall, VPN, router or intrusion detection system, and thus will require multiple network adapters to connect to the various networks its services.

1. Edit Settings of the target VM

2. In the Virtual Hardware tab, at the bottom of the dialog box, click the New Device —-Select—- list

3. From the list select Network, and then Click Add

Screen Shot 2014-04-09 at 11.57.36.png

4. Expand the >New Network and select the Portgroup you require, and the NIC Driver type

Screen Shot 2014-04-09 at 11.58.40.png

Modern operating systems such as Windows 2012 R2 should plug-and-pray the network device, although you will need to set the IP address if you require a static IP.

Hot Adding Memory and CPU

Most modern operating system support the hot-add of both CPU and Memory. However, the older the operating system the more likely the right type from a licensing perspective will be required – or you will find that the OS supports hot add of memory or CPU but not both together. Somewhat ironically, hot-add is not enable by default on a VM, and ironically requires that the VM should be powered down to enable the feature. Therefore if your serious about requiring the hot-add memory/CPU feature its worth encoding this option in your templates. Remember that until very recently any increases in memory/CPU require a total shutdown of the OS and machine (physical or virtual), and it is something that many administrator plan a maintenance window around. Its worth saying that its is difficult to predict if an application will see the new memory/CPU resources – application developers often deviate from common standards via accidentally following out of date guidelines – and this can make the application or service misbehaves, and requires a restart to see the new resources. It is a given that the application must be “multi-threaded” to be able utilise more than one CPU core. Despite the now endemic use of multi-core processors this isn’t alway the case. Finally, enabling hot-add is not necessarily a positive function.

As Duncan Epping made clear on a blogpost in January 2012:

Lets answer the impact/overhead portion first, yes there is an overhead. It is in the range of percents. You might ask yourself where this overhead is coming from and if that is vSphere overhead or… When CPU and Memory Hot-add is enabled the Guest OS, especially Windows, will accommodate for all possible memory and CPU changes. For CPU is will take the max amount of vCPUs into account, so with vSphere 5 that would be 32. For memory it will take 16 x power-on memory in to account, as that is the max you can provision . Does it have an impact? Again, a matter of percents. It could also lead to problems however when you don’t have sufficient memory provisioned as described in this KB by Microsoft: http://support.microsoft.com/kb/913568. Another impact, mentioned by Valentin (VMware), is the fact that on ESXi 5.0 vNUMA would not be used if you had the HotAdd feature enabled for that VM. What is our recommendation? Enable it only when you need it. Yes they impact might be small, but if you don’t need it why would you incur it?!

1. First shutdown the guest operating system and VM with a right-click and Shutdown Guest OS

2. Edit Settings of the VM, and under the Virtual Hardware tab, expand >CPU

3. Enable the option X Enable CPU Hot Add

Screen Shot 2014-04-09 at 12.37.51.png

4. Next expand >Memory and enable X Memory Hot Plug

Screen Shot 2014-04-09 at 12.43.42.png

Once enabled and the VM is powered on, you should notice in the Edit Settings dialog box, that CPU and Memory are no longer restricted and can be modified.

Screen Shot 2014-04-09 at 15.02.51.png

In the example below memory was increased from 4GB to 8GB, and the vCPU count was doubled from 2 vCPUs to 4 vCPUs

Screen Shot 2014-04-09 at 15.06.10.png

Managing Virtual Machine Snapshots (Web Client)

Snapshots offer a way of capturing the VM memory and disk state prior to making any changes. It’s particularly useful in situations where the outcome of given action is unknown, and the administrator wants a quick and easy way to roll-back any changes made. A typical example might be some software upgrade for instance. When a snapshot is taken all the drives that make up the VM are snapped, this means data loss could occur when reverting the snapshot on data volumes. So care must be taken to stop end-users connecting and making changes.

More commonly, Snapshots are used in virtual machine backups. This is where running backup agent within the guest operating system is dispensed with, and instead backup is taken of their virtual disks. Snapshots allow release the file system locks that normally persist, and allows the backup software to back up the virtual disks. Since the advert of “Change Block Tracking” (CBT), backups this way are as efficient from speed and space perspective as any in-guest backup agent. The first backup takes a normal back up of the VM, and subsequent backups are taken merely of the blocks that have changed since that backup.

Snapshot work by creating a copy of the contents of memory, and saving this to a file – this allows a snapshot to be taken whilst the VM is running, and indeed it allows for the quiescing of the file system leveraging components within the guest operating system such as Microsoft’s Volume Shadow Copy feature. The time it takes to create a snapshot is dependent on the amount of memory allocated to the VM, and the time it takes to create this snapshot file. Whilst a snapshot is being created, at same time a “delta” virtual disk is create for each virtual disk allocated to the VM. This normally takes the format of <virtualmachinename>0000N.vmdk. This file starts its life as 16MB in size, and grows as changes accrue in the VM. When a VM snapshot is “deleted” the contents of the delta is copied into the regular virtual disk, and the snapshot files discarded, along with the memory file.

Screen Shot 2014-04-09 at 16.33.29.png

Note: The .VMSN is the memory contents of the VM. win2012R2-00001.vmdk is the delta virtual disk snaphot file. .VMSD is a small management file that keeps record of snapshot taken.

When a snapshot is “reverted” the content of the delta file is discarded, and the memory state file restore to the VM – thus rolling it back to its previous state. Snapshot can revert other virtual machine file such as the .VMX file which holds the VM’s core settings. This can make to the VMs settings such as modifying the portgroup assignment, and then the VM is reverted it is relocated back to the original portgroup.

As such snapshots are regarded as temporary files and should not be allowed to persist on the VM for extended periods – they can degrade performance; fill up datastores; and if reverted after a long period cause problems elsewhere – such as breaking the computer account trust relationship between a Windows VM and its Active Directory Domain.

Taking a Snapshot

A good way to test and demonstrate the effect of snapshots is to take one with VM with file open, and unsaved with data inside it…

Screen Shot 2014-04-09 at 16.22.10.png

1. Right-click the VM, and select Take Snapshot

Screen Shot 2014-04-09 at 15.56.52.png

2. Type a friendly name for the snapshot, and take time to provide a good description – it is useful to other administrator to include such details as who took the snapshot, when and for what purpose

Screen Shot 2014-04-09 at 16.07.45.png

3. Once the Snapshot has completed, you can make changes – go crazy!

Screen Shot 2014-04-09 at 16.25.39.png

Reverting a Snapshot

Reverting the state of the VM will restore the VM back to its condition before changes – this is like a big “undo” button on the VM. But be careful the revert or undo process will undo your changes – good and bad…

1. Right-click the VM, and select Revert to Latest Snapshot

Screen Shot 2014-04-09 at 16.40.41.png

Note: Manage Snapshot can be used to handle multiple snapshots.

2. Acknowledge the warning that “The current state of the virtual machine will be lost unless it is saved in a snapshot. Revert to latest (most recent) snapshot?”. Remember any currently connected users with active sessions will be lost.

Screen Shot 2014-04-09 at 16.42.53.png

3. After a short while the VM will be reverted back to its previous state.

IMPORTANT: The snapshot is still present – and the delta file(s) will be still growing. But at least there is no hideous pink colour – shame about the changes made at 16.23.

Screen Shot 2014-04-09 at 16.45.13.png

Deleting a Snapshot

Deleting a snapshot does not mean you will loose data. It means the contents of the snapshot delta .vmdk files will copied into the regular .VMDK files – and you changes will be saved. The only thing that is discarded is the old, out of date memory contents, which is no longer required. The best way to demonstrate this is to make some changes you do want to retain.

Screen Shot 2014-04-09 at 16.50.12.png

Note: It is not recommended to save your credit card details to plain text file and store it on your desktop.

1. Right-click the VM, and select Manage Snapshots

Screen Shot 2014-04-09 at 16.40.41.png

2. This dialog box allows to see multiple snapshots (presented in parent-child-parent-child manner). It gives you the opportunity to not just revert to the latest snapshot – but to ones before it. Additionally, it gives the administrator to roll-up all the snapshots, and apply them to the VM using the Delete and Delete All buttons. With just one snapshot delete and delete all is the same action.

Screen Shot 2014-04-09 at 16.52.59.png

If you click Delete All, the dialog box indicates that the snapshots will be consolidates into a single disk

Screen Shot 2014-04-09 at 16.56.17.png

This should result in retention of all the changes accrued during the use of the snapshot.

Screen Shot 2014-04-09 at 17.05.47.png

Importing and Exporting Virtual Machine/Appliances Template

Virtual Machines and Appliance can be imported and exported using the Web Client. VMware supports the “Open Virtual Machine Format” or .OVF format which consists of an .OVF, VMX and VMDK files which are uncompressed (although are commonly bundled together in .zip format to allow for ease of download) and also the .OVA package which is actually a .tar archive containing the .OVF files. Both OVA and OVF are natively supported by the Web Client, however, there are some technologies such as VMware vCloud Director that only support the .OVF format. As .OVA packages are merely .tar achives they can be extracted, and imported using the native .OVF descriptor file in needed.

One good example of using pre-packaged OVF/OVA virtual machine is so called “Skinny Linux” distributions. These are popular in homelabs where memory and diskspace maybe at a premium. These distributions of Linux use an incredibly small amount of resources, and allow SysAdmins to build lab environments that look and feel much larger than than they actually are. The sources of this distributions are many and varied but often they start the lives as recovery CD-ROMs, which have been installed to disk. However, these Linux distributions are not with limits – they are often not supported by VMware, have very small disk sizes based on IDE virtual disks, and frequently do not contain VMware Tools. This means that features such as reporting the IP address of the VM, or soft reboot/shutdown options are not available. Examples include SliTax and TTYLinux available on mikelaverick.com and DSL hosted on virtualmikebrown.com

Importing an OVF/OVA Template:

OVFS/OVAs can be downloaded from the owners website first, and then imported into vCenter – alternatively if you know the URL for OVF/OVA you can import it directly into vCenter assuming that there is no special authentication required or firewall restrictions

1. Right-click the Datacenter/Cluster or Host that you wish to use for the OVF/OVA import select Deploy OVF Template

Screen Shot 2014-04-22 at 12.18.15.png

2. Either paste the URL for the OVF/OVA OR use the Local File option to Browse for the location to which it has been downloaded

Screen Shot 2014-04-22 at 12.19.47.png

3. Read the Review Details page. In commercially available virtual appliance expect to see the Version, Vendor and Publisher fields to be completed

Screen Shot 2014-04-22 at 12.20.58.png

4. Type a friendly name, and select inventory location in vCenter for the new VM

Screen Shot 2014-04-22 at 12.21.43.png

5. Select a virtual disk format, together with a datastore for the VM

Screen Shot 2014-04-22 at 12.22.28.png

6. Configure the VM’s network settings, by selecting a portgroup for the VM

Screen Shot 2014-04-22 at 12.23.01.png

7. Finally, indicate whether you would like the VM to be powered on after the import process has completed – and click Finish.

Screen Shot 2014-04-22 at 12.24.18.png

Exporting to OVF/OVA Template:

The vCenter Web Client supports the exporting of any VM into either the OVF or OVA format. For those people wanting to have full control over the process of building a virtual appliance, there is the free VMware Studio distribution that assists in this process. It is a free development tool for authoring, updating and managing virtual appliances and vApps that are optimized for VMware product platforms. Remember a VM encapsulates the operating system and all the applications installed to it – so care must be taken not to breach any license restrictions and agreements.

1. Right-click the target VM, and select All vCenter Actions, and Export OVF Template

Screen Shot 2014-04-22 at 12.43.38.png

2. Type a friendly generic name for the exported VM

Note: If OVF is used as the format, this creates directory by the configured name within which the OVF files are held with the same name. If OVA is selected a single compressed .OVA file created at the location specified with the choose button.

3. Use the Choose button to select a location to export the OVA/OVF file

4. Under Format, select the type of export either OVF or OVA

5. In Annotation provide a friendly description of the OVF/OVA

Screen Shot 2014-04-22 at 12.48.24.png

Note: As the dialog box indicates, the advanced options expose attributes that could decrease the portability of the VM.

Creating and Modifying Virtual Machines (PowerCLI)

Screen Shot 2013-10-21 at 14.01.16.png

Although its unlikely that many will want to create a clean blank virtual machine using PowerCLI. It is indeed possible – but administrator may find more use from creating new VMs from existing ones or from templates.

Creating a VM requires knowing what GuestID value to use for the corresponding operating system – this is referred to as the VirtualMachineGuestOsIdentifier. A list of VirtualMachineGuestOsIdentifier’s which maps the GuestID parameter to the friendly name is available in the SDK documentation: VirtualMachineGuestOsIdentifier. For instance Microsoft Windows 2012 R2 is known as “windows8Server64Guest”.

The first line of this PowerCLI creates a new Windows 2012 R2 VM called CorpHQApp01 on the GoldCluster01 using the datastore called Bronze. The VM is allocated 2-vCPUs, 4GB RAM and thin virtual disk of 40GB in size connected to the portgroup called VLAN101. The second line adds the CD-Rom Device and connects the win2012R2.iso held on the software datastore.

Creating a Virtual Machine:

New-VM -Name CorpHQApp01 -ResourcePool GoldCluster01 -Datastore Bronze -NumCPU 2 -MemoryMB 4096 -DiskMB 40000  -DiskStorageFormat Thin -GuestID "windows8Server64Guest" -NetworkName "VLAN101"
$cd = New-CDDrive -VM CorpHQApp01 -ISOPath "[software] microsoft/win2012R2.iso" -StartConnected
Start-VM -VM CorpHQApp01

List and Disconnect VMs with Connected CD-ROM Device

Typical vCenter Admins will connect up CD-ROM Devices, and then forget to disconnect them. The CD-ROM Device isn’t a truly virtualized device and it can be drain on resources, and cause problems elsewhere.

This PowerCLI one-liner will list all the VMs that have CD-ROM Device Connected. The CD-ROM is not regarded as “connected” if a VM is configured for it – but the VM is powered off. So only powered on VMs, which an actively connected CD-ROM Device will be found with this PowerCLI script.

Get-VM | where { $_ | Get-CDdrive | where { $_.ConnectionState.Connected -eq "true" } } | select Name

This PowerCLI one-liner will list all the VMs which have path set for either datastore ISO or the physical DVD-Drive of the VMware ESXi host.

Get-VM | where { $_ | Get-CDdrive | where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } } | select Name

This PowerCLI two-liner disconnects any CD-ROM Device found to be connected, and then unconfigures any VM set to use an ISO file or the host’s physical DVD Device.

Get-VM | Get-CDDrive | Where {$_.ConnectionState.Connected} | Set-CDDrive -connected 0 -StartConnected 0 -Confirm:$false 
Get-VM | Get-CDDrive | Where { $_.IsoPath.Length -gt 0 -OR $_.HostDevice.Length -gt 0 } | Set-CDDrive -NoMedia -Confirm:$False 

List VMs which require a VMware Tools upgrade:

Using the ExtensionData.Guest.ToolsStatus value we can query the state of VMware Tools on the VMs.

Write-Host "================================================================"
Write-Host "These VMs need VMware Tools updating"
Write-Host "================================================================"

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsStatus -eq "toolsOld"}

Write-Host "================================================================"
Write-Host "These VMs are powered on, and do not have VMware Tools installed"
Write-Host "================================================================"

Get-VM | where {$_.powerstate -match "On"} | Where-Object {$_.ExtensionData.Guest.ToolsStatus -eq "ToolsNotInstalled"}

Enable Time Synchronisation and Upgrade Tools on Power On:

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
$vmConfigspec.Tools.syncTimeWithHost = $true

Get-VM | %{
     $_.Extensiondata.ReconfigVM($vmConfigSpec)
}

Managing Virtual Machines Snapshots (PowerCLI)

Screen Shot 2013-10-21 at 14.01.16.png

Creating a Snapshot:

Creating a snapshot can be done using the New-Snapshot cmdlet which supports flags for capturing the memory contents, and also quiescing disk activity during this process.

New-Snapshot -VM win2012R2 -Memory -Quiesce -Name "Test Snapshot" -Description "Created by: mikelaverick@corp.com Date: 09-Apr-2014 Reason: Before Windows Update" 

Reverting a Snapshot:

$snapshot = Get-Snapshot -VM win2012R2 -Name "Test Snapshot" 
Remove-Snapshot -Snapshot $snapshot -RemoveChildren -Confirm:$false

Deleting a Snapshot:

The Remove-Snapshot cmdlet take the snapshot and deletes it, the -RemoveChildren flag takes all the snapshots and consolidates them into a single virtual disk file.

$snapshot = Get-Snapshot -VM win2012R2 -Name "Test Snapshot" 
Remove-Snapshot -Snapshot $snapshot -RemoveChildren -Confirm:$false

Locating VMs with Snapshots:

Typically, vCenter Admins snapshot a VM(s) and then forget that they have. So the worry is that lots of VMs can build up with uncommitted snapshots cause an outage by them running out of disk space or cause poor performance when engaged for long periods of time. This script search the entire vCenter Inventory return all VMs that have a snapshot, and use the Select command to report on various attributes including the date they were created and how big the snapshots are – finally it sorts the report by the Created date – showing the oldest snapshots at the top of the list. This is just one example/sample – there are many more sophisticated scripts that report on the snapshot status.

Get-VM | Get-Snapshot | Select Created, VM, Description, SizeMB | Sort Created

Bulk Snapshot VMs by Wildcard:

You can snapshot a group of VMs by either having a very good naming convention, and using wildcards to identify the VMs, or using other filters such as every VM in a particular VM folder for instance.

New-Snapshot -VM CorpHQ* -Memory -Quiesce  -Name "Test Snapshot" -Description "Created by: mikelaverick@corp.com Date: 09-Apr-2014 Reason: Before Windows Update" 

Bulk Delete the VM Snapshot:

Foreach ($vm in get-vm CorpHQ*)
{
 $snaps = get-snapshot -vm $vm
 remove-snapshot -snapshot $snaps -RemoveChildren -confirm:$false
}

“Advanced” Virtual Machine Administration

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

Screen Shot 2014-04-23 at 13.41.04.png

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

Screen Shot 2014-04-23 at 14.02.23.png

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.

Screen Shot 2014-04-23 at 14.08.15.png

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

Thick-lazy.png

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

Thin.png

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.

Screen Shot 2014-04-23 at 15.27.07.png

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.

Screen Shot 2014-04-23 at 15.38.03.png

Screen Shot 2014-04-23 at 15.38.14.png

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.

Screen Shot 2014-04-25 at 10.42.54.png

Configuring Virtual Disks Modes

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

Screen Shot 2014-04-23 at 15.53.04.png

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

Screen Shot 2014-04-25 at 13.12.49.png

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.

Screen Shot 2014-04-23 at 16.29.15.png

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.

Screen Shot 2014-04-23 at 17.06.40.png

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:

Screen Shot 2014-04-23 at 16.50.57.png

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

Screen Shot 2014-04-24 at 09.24.35.png

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

Screen Shot 2014-04-24 at 09.31.52.png

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

Screen Shot 2014-04-24 at 09.44.50.png

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

Screen Shot 2014-04-24 at 09.41.51.png

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

Screen Shot 2014-04-24 at 09.50.55.png

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 athttp://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…

Screen Shot 2014-04-24 at 12.18.41.png

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.

Screen Shot 2014-04-24 at 12.23.10.png

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

Screen Shot 2014-04-24 at 12.47.51.png

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

Screen Shot 2014-04-24 at 12.48.14.png

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

Screen Shot 2014-04-24 at 12.48.27.png

Screen Shot 2014-04-24 at 12.48.57.png

Screen Shot 2014-04-24 at 12.49.24.png

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

Screen Shot 2014-04-24 at 13.39.43.png

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

Screen Shot 2014-04-24 at 13.40.19.png

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

Screen Shot 2014-04-24 at 13.51.05.png

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 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:

Screen Shot 2014-04-24 at 14.34.15.png

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.

Screen Shot 2014-04-24 at 15.29.01.png

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

Screen Shot 2014-04-24 at 15.53.50.png

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

Screen Shot 2014-04-24 at 15.57.26.png

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

Screen Shot 2014-04-24 at 16.13.21.png

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

Screen Shot 2014-04-24 at 16.16.17.png

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

Screen Shot 2014-04-24 at 16.16.40.png

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.

Screen Shot 2014-04-24 at 16.17.39.png

Using N-Port ID Virtualization (NPIV) [Placeholder-TBA]
Using Source Root Virtualization IO (SRV-IO) [Placeholder-TBA]

Source: http://www.mikelaverick.com/wiki/index.php?title=Creating_and_Modifying_Virtual_Machines

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s