Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

This is a hard question to ask as I know very little about this topic. Please bear with me.

From my perspective, supporting a relatively small number of machines, the notion of virtualization has one intriguing benefit: hardware independence. Perhaps that's not the right way of saying it, but I really like the idea of being able to take an entire machine and move it to any adequate piece of hardware.

I know this is possible, of course, but things seem to get tricky when it comes to virtual disks and performance. If you're using pass through to disk then your virtual machine is still bound to a certain piece of hardware.

Are there technologies today that allow a person to easily package up a machine and its disks and move them to different hardware in such a way that I/O performance isn't greatly impacted? As easy as copying a virtual disk image to a new machine? Is this possible with free solutions from vmware, Microsoft, and the like?

(When I speak of performance, I'm not talking about anything big time... just standard small to medium business solutions: ERP, mail, etc)

share|improve this question

4 Answers 4

up vote 2 down vote accepted

I don't think you're asking about live migration features like VMotion. I think you're just asking:

How to I do things like expose raw block devices / LUNs to my VMs ("IO pass through"), which I've heard gives better performance than using virtual disk files inside filesystems managed by the hypervisor w/o giving up the hardware-independent nature of my VMs?

You've identified a tradeoff scenario. Removing layers of abstraction can make things run faster, but you're giving up the benefits of the abstraction in doing so. If you find that you need to expose raw block device to your VMs for performance reasons, then either plan on being "tied to" those block devices, or use something like SAN-level replication to gain some device independence on a lower level (possibly with its own set of performance tradeoffs).

Personally, I'd try and stay in the comfortable world of virtual disks as much as possible. The abstraction offers significant benefit.

share|improve this answer
    
Thank you Evan, that's exactly what I was trying to get at. I have some upgrades coming and not a lot of time or resources. I'd like to experiment with virtualization if it will pay off. Do you feel that it's feasible to run software like Exchange 2007 on a virtual disk in a small environment? (40 or so clients, 30GB store, reasonably decent RAID 5 & 6 storage available) If so, I'll invest some time into seeing if it'll work. –  Boden Nov 9 '09 at 21:53
    
Yes, you can get Exchange to run in a virtual environment without much trouble. VMWare has white papers on how to do it. –  Bart Silverstrim Nov 9 '09 at 22:42
    
Boden - that is definitely doable. If you can go with Exchange 2010 (released today), it has even lower disk performance requirements and I don't think I would considering deploying it on physical hardware anymore. –  Doug Luxem Nov 9 '09 at 22:44

You should expect similar disk performance, especially when using raw LUNs on a SAN.

A common scenario where disk performance is impacted is when the partition is not aligned. Windows 2003 and earlier did some brain-damaged things when creating a new partition, it would start at the 64th sector. The upshot is os partition is misaligned with the physical volume. The result is that single clusters of user data are written across multiple stripe units of the RAID. Every nth operation is affected (n depends on file allocation unit (cluster) size and stripe unit size). This is all documented quite well on both the VMWare and Microsoft web sites.

It's not unusual to improve performance 20-40% when partitions are properly aligned.

You may also improve performance by using a larger NTFS allocation unit size, such as 8k. But you must use 4k for the system partition (where ntldr resides).

More information:

http://msdn.microsoft.com/en-us/library/dd758814.aspx

Also check out the Windows 7/Windows 2008 R2 new feature, boot from vhd:

http://blogs.technet.com/jamesone/archive/2009/08/17/how-to-boot-from-vhd-vhd-booting-re-visited.aspx

share|improve this answer

Hardware independence is exactly the right way to look at it - separating the services you rely on from the hardware is a major benefit that virtualization offers.

Your question about portability and IO performance isn't totally clear but I think I can see what you are getting at.

Pretty much all hypervisors, certainly all of the mainstream ones ( VMware, Microsoft, Xen, KVM) allow you to shut down a VM and move it to different storage or to a completely different host without any issue, your only problem will be dealing with the fact that you are usually copying a very large amount of data. Most of the vendors have a number of Hypervisors and, in general, its pretty straighforward to move a VM from (say) VMware Workstation to VMware Server to VMware ESX. Moving between Hypervisor vendors is a little harder and will involve some conversion but again all of the major vendors support this to some degree. In general, provided a VM is powered off, it can be moved with no more trouble than copying a large file.

Moving VM's with minimal (or no) downtime is a lot harder but all of the major vendors provide some version of this now. With VMware it's called VMotion, Microsoft call it Live Migration, Citrix (Xen) call it XenMotion or Live Motion. All of these require shared storage (a SAN or NAS) and enforce fairly rigid restrictions on the variety of hardware you can have in your cluster but they will allow you to move a running VM from one host to a different one in a managed cluster with near zero (millisecond\sub-millisecond range) interruption in services. This is a highly desirable feature and tends to require expensive licenses as Bart Silverstrim pointed out in his answer but Microsoft's HyperV 2008 R2 Server allows you to build such a cluster using only free (as in beer) components which is quite interesting as do Citrix . The cheapest licenses from VMware that support this cost around $2k per CPU if I recall correctly, but you can't really argue with the Citrix or Microsoft price point if you want to build something small. VMware is arguably the best of the bunch but you have to pay quite a lot to get everything from it, Xen is more mature than Hyper-V but Microsoft have made huge progress over the past 18-24 months so shouldn't be discounted. Vmotion\Live Migration has no major impact on Disk IO performance.

A variation of VMotion\Live Migration involves leaving the VM running on the same host but moves the underlying storage location without bringing the VM down. This is an even more expensive licensing option from VMware (they call it Storage VMotion), Microsoft have a "Quick Storage Migration" that is similar but not totally seamless as far as I'm aware. Note the copy process still takes a long time and it will have an impact, possibly a significant impact, on overall storage performance while the migration takes place.

In terms of VM hard drive performance you should keep a few things in mind. The Hypervisors are all pretty good - you should expect to see 80%+ of native performance even under extreme conditions and for the most part unless you have very weird storage IO patterns you can safely assume 95% or better. Basically a well planned implementation with a good storage subsystem should be hard to tell apart from a native solution. You need to know how much performance your VM's will need and then you need to provide that plus any additional performance that you need to provide anything extra (like Live Migration\failover capacity etc). As with anything else (CPU, Memory, Network Bandwidth) if you fail to provide enough storage capacity (sequential bandwidth, space, IOPS) then your solution will perform badly. The best way to approach planning for these is to get a good idea of the total storage characteristics that you need (again GB of usable space, Peak total IOPS, Peak bandwidth) add on whatever you need for imminent growth and make sure the storage solution that you put in place can provide that.

As a general rule for VM hosting environments spend money on memory, make sure you have enough CPU power and for storage (at least until we get cheap SSD storage) buy a good RAID controller\SAN\NAS and try to buy as many disks as you can - 2TB of storage that comes from 8x250GB disks will substantially outperform 2x1TB disks all other things being equal.

share|improve this answer
    
Thanks very much. I've only played around with this a little bit using KVM and VirtualPC. It was my understanding that virtual disk performance was considered to be rather poor, and could be alleviated by mounting a native filesystem partition from the VM... which of course negates the simple "portability" benefit of virtualization. I'm glad to hear, if I understand you correctly, that this may not be as big of an issue as I thought it would be. –  Boden Nov 9 '09 at 20:23
    
For hosted Hypervisors (like Virtual PC\KVM\VMware Server etc) you are often sharing a single drive with multiple OS's and this is automatically going to put things under stress. In a well designed Virtual environment for hosting production systems in VM's you still need to have a storage subsystem that can deliver the performance you need (which might require many disks\arrays) but you don't need to factor in a huge penalty because they are virtualized, for most scenarios at any rate. –  Helvick Nov 9 '09 at 20:36

VMWare ESXi is free. Specific with it's hardware requirements though. Most are.

Xen can be rigged up for semi-automatic failover. (I mean Xen, not the xen based product from Citrix...this is referring to using Heartbeat and fencing and lots of manual futzing around with Linux to get failover support).

It all depends on what you expect for "quick moving". Vmotion is paid for as an add-on, and it's not cheap, from VMWare, but allows you to seamlessly move VM's from server 1 to server 2 without interruption, and usually requires some means of shared storage between the two servers.

We have a system in place for bringing servers up relatively quickly but it involves copying snapshots of our virtual machines to another location and running VMWare from there. The copy (backup) takes hours to do though and I normally take the servers offline for part of the weekend to do it. The nature of our servers lets us get away with going offline for that period of time though. If you're talking about something that has to be up 24/7, this will definitely not work.

For an inexpensive setup you can try assembling a couple "white box" servers (Google is your friend) for ~$500 a piece that will be compatible with VMWare ESXi to run that free, then you can work on a backup solution to copy VM's between the two periodically (Veeam had some free copy utilities, don't know if VMWare required them to disable it for the ESXi product by now though). Then if you have hardware failure you can bring a fairly recent backup online quickly. Or if you have fast external storage you can use that to share between the two servers so if the server died you can fire up the second one fairly quickly.

Most solutions I know of for maximum uptime, things like VMotion, are what are paid for in Xen and VMWare based solutions. Enterprise features are their moneymakers. Moving VM's seamlessly are exactly the market willing to pay for those features. Either way you need to have a good plan in place for backups whether of the VM's themselves or coupled with backup agents on the virtualized servers so at a minimum you could create new blank slate servers on another VM and restore from your backed up virtual servers as if they were bare metal. If using shared storage you should plan on good backups for that in case of drive failure.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.