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.

The Future of VDI in 2010

It is doubtless there is going to be a lot of traction in the VDI arena in the coming year fuelled by Windows7 and the continued uptake of Server Virtualization. I see many POC's in process and operations asking how can VDI fit with their user demographics and business profile, and I have to admit it does make sense to least put all this on the table and at least discuss.

I see Citrix and Vmware have majority play in this arena due to the maturity, functionality and scalability of their product suites.

I do not want to get into the discussion of Terminal Server versus VDI all I will say is that I believe they have different use cases and will coexist in most environments and there will be a shift towards a true managed desktop. I have just watched some interesting interviews with the Vmware Desktop CTO Scott Davis and Citrix Desktop CTO Harry Labana on the views on the current and future road maps for both their products

They both agree that VDI is not the finished article and their will be interesting developments around client hypervisors this year.

I also agree that desktop virtualization has a lot of user interaction as opposed to server virtualization which has minimal interaction and thus creates it's own set of problems. I think for a true managed VDI desktop you will need to take a layer cake approach for the OS, Applications, User data and profiles to be truly effective but this means you need to use the likes third party products like Appsense and App-V which brings the CAPEX up considerably.

The main problem I see with Citrix Xendesktop and Vmware View is that their disk provisioning technologies (provisioning server and View composer) do not really work as they say on the tin. The main goal of these provisioning technologies are have a "Gold Image" to save disk space and make operations aligned with deployment and patching more streamlined.

Recent advancements in Vsphere with thin-provisioning at Virtual machine level make disk space less of priority and the main bugbear is as all Gold images will have a master image and linked differential file if you need to update the master image you  lose any information in the differential file as this is at block level. This can cause issues if you want a persistent image due user defined data kept in the delta file or if the master is recomposed you will see the same issues again around this data.

Brain Madden has wrote a great explanation here:

http://www.brianmadden.com/blogs/brianmadden/archive/2009/02/18/brian-dump-atlantis-computing-hopes-to-solve-the-quot-file-based-quot-versus-quot-block-based-quot-vdi-disk-image-challenge.aspx

It is far simpler to either to take an one-2-one approach to your image or use non persistent "gold images" .

Let see how it things pan out this year...