In trying to establish feature comparisons among VMware ESX 3, Virtual Iron 3.5, and Xen 3, I've come up with a few questions that I can't seem to answer on my own. Any answers would be appreciated. 1. Does Virtual Iron support memory oversubscription similar to the way that ESX does? I'm thinking not, but don't knowfor sure. 2. Can I move a Virtual Iron VM from Virtual Iron to a XEN environment? I'm interested here mostly for portability -- some people don't want to be locked in to a certain vendor 3. What densities are people seeing with Virtual Iron? (5:1, 10:1, 20:1?) 4. Does Virtual Iron implement any paravirtualization capabilities like Xen (for open source OSes), or does it rely solely on the Full virtualization? I'm thinking the latter. 5. Does Virtual Iron handle RTC/descheduling issues better than/as well as ESX? 6. Is it possible to grow Virtual Iron VM disks? (in the manner of extending a .VMDK file in an ESX world)

Thanks for looking at Virtual Iron! Here are answers to your questions:

1) We do not have memory oversubscription in version 3.5. However, we've found that since memory is less expensive than VMware's software, you still come out ahead with Virtual Iron.

2) Virtual Iron supports the Microsoft VHD format, which allows you to import virtual appliances and use utilities that support VHD.

3) Densities vary by workload, but a rule of thumb is about 5 virtual servers per CPU.

4) Virtual Iron supports full virtualization for all supported operating systems. Virtual Iron has optional paravirtualized drivers, called VSTools, that improve IO performance.

5) I am not familiar with this aspect of ESX.

6) It is not possible to dynamically grow a virtual disk in version 3.5.

Thank you for the quick responses! As for #5, in my experience, there has always been a limitation with virtualization as far as the real-time clock is concerned. When the operating system starts up, it reads the current time to the nearest second from the computer's (CMOS) real time clock or queries a network time server. To update the time from that point on, the operating system sets up one of the computer's hardware timekeeping devices to interrupt periodically at a known rate (say, 100 or 1000 times per second). The operating system then fields these interrupts and keeps a count to determine how much time has passed. Because a VM only runs while its context is active on the CPU, its clock is not updated in realtime -- when the interrupt is triggered, the VM may not actually be running. That means that the clock in each VM may be behind the next time it is allowed to run on the processor. Unless the VM somehow adjusts its clock, this time difference accumulates. This is obviously a simplistic example, but I hope you get the idea. I recall a Xen recommendation to sync the host (dom0) with NTP and configure the guests (domU) with a parameter called independent_wallclock=0 to effectively slave them to the host's clock. -- that had issues, so the recommendation was to use NTP in all of the guests (some folks used a cron job to constantly sync via NTP) and set independent_wallclock=1 in all guests. I'm looking for differentiators

I am from ESX2.5.3 world - doing comparisions - so will add input -

1. ESX allows more memory to be allocated than real - this doesnot exist in VI.
2. See VI blog - convert esx disk to MS vhd and then pla it in VI (havent done it - but logically - should work)
3. Density-Its a question that will depend on your workload. My experience - VI is good but it spikes every few seconds - ESX is very very (I repeat VERY) mature product. VI is still "getting there" - but then - it doesnt mean that VI is not workable - It works- and works well (thought nowhere to the maturity level of VMware)
4.VI is Xen with different clothes (I know its going to attract heated arguments)
5. Most of my machines (I have 8 productions machines in dual 2.8Ghz, 4GB on ESX2.5.3) are low use - and I never had clock slip/fast issue. I am using ESX2.5.3 and I have seen ESX3 handles it even better. VI - For last 2 days - 3 test machines - no time slip - I will stress the machines today and will update. In short - in my setup - I never had issue with VMware time slip and neither with VI.
6. You got answer from Cbarclay - but then - since VI uses VHD, utilities should exist in which you stop the machines, take the VHD, grow it, start the machines again. VHD is almost open format - try googling (I have no experience - just thinking loud)

All this above feedback is based on 48 hrs experience of VI only - I may be wrong.

But the selling poing of VI can be - Boot it from white box (it supports standard chipsets, boots from SATA) and then store the VHDs on inexpensive software iSCSI. The documentation is REALLY bad - its super confusing - but when you install - everything is crystal clear (except for nagging commit button). There should be faq column esp for single server install - separate from multi server. 

Hello- I'm running the doc team over here at VI. Can you tell me what you have found confusing about the documentation set? The more specific you can be, the better. Any suggestions or insights you can offer will be greatly appreciated. Thanks-