Snapshot Script for Vsphere using yULM

I have found this really cool script for presenting a graphical view of a snapshot chain within Vsphere via PowerCLI http://www.lucd.info/2010/03/31/uml-diagram-your-vm-vdisks-and-snapshots/

I have amended the Script to include the functionality to work in a corporate environment behind a proxy server, you simply need to change the following two lines to reflect your target server name and proxy address.

$vmName = "Servername"

$diagram = Get-UMLDiagram $vmName Get-yUMLDiagram $diagram "C:\test\yULM.jpg" -show -proxy "10.*.*.*:8080"
Snapshot

The Changing face of VDI

I have spoke about this before, but I think there will be a huge amount of traction in the VDI space of the next 18 months, the main drivers as below

1. Windows 7 adoption - a catalyst for change and a great product, it makes sense to at the very least evaluate VDI when deploying.
2. Xendesktop 4/Vmware View - Both these products are now on release 4 are much more mature.
3. VECD - This has now been scrapped by Microsoft for customers running Software Assurance.
4. Unidesk - A product that ticks all the boxes when it comes to a fully managed desktop solution to dovetail with VDI, its in Beta at the moment but I am testing as we speak and will come back with a full review.
5. Apple IPAD - I think this will be a usefull in some select business environments combined with a Citrix Client.
6. Citrix Xen- Hyper-V - Upcoming memory over-commit support means more desktop density and thus better TCO.

Let see how things pan out....

Vmotion in Vsphere

I have just read something which had me thinking, should you increase the amount of Vmotions on a Vsphere host, from the current limitation of two per host. This can be easily achieved by editing the vpdx.cfg file on your virtual centre server as in this post http://www.boche.net/blog/?p=806. I tend to think it's there for a reason and in my experience I would advise against it.

Ok so whats my thinking behind this?  Well if you examine the actual Vmotion process there are some caveats in there that could cause performance issues if you there is a lot of I/O (I am thinking Database and Application servers here)

The following below is the Vmotion Process in depth as I understand it

1: Command sent to VC to check prerequisites 

2: Provision new VM on target host

3: Precopy memory from source to target, with ongoing memory changes logged in a memory bitmap

4: Quiesce VM on the source host and copy memory bitmap to target host

5: Start VM on target host

6: "Demand page" the source VM when applications attempt to read/write modified memory

7: Note - The new VM comes up before ALL the memory is copied over. We can do this, because once the initial copy has taken place, subsequent changes to the app touch only a fraction of all the memory pages.

8: "Background page" the source VM until all memory has been successfully copied

9: Delete VM from source host

I think the important issue here is point 5, the Virtual machine starts on the new Vsphere host BEFORE the memory map is copied over.

I have seen issues in a production environment whereby you Vmotion from a host running at high Memory utilisation and with a guest with that has a lot of current I/O, it will become very slow and unresponsive. In essence it seems that when the VM is migrated a memory delta file will be created on the source host. This will then be copied to the target host, and if there is a shortage of physical memory on the source host a disk based swap file will be used which is considerably slower and hence possible performance issues.

So to sum up the more concurrent Vmotions you run the more risk you have of problems.