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

On a guest Windows OS under VMWare ESXi, is configuring software raid 1 between 2 virtual disks, residing on 2 seperate physical disks, a good idea? Performance, scalability, managability and fault-tolerance -wise?

EDIT: To clarify: The idea is 2 seperate physical drives, 2 datastores, and no other VM to use them. Also, RDM is not an option for me in this case.

share|improve this question

3 Answers 3

up vote 1 down vote accepted

Fault tolerance will be the same, but I think your performance and manageability will suffer compared to doing RAID1 on the host, especially if you have any other VMs using those same disks.

For one, doing software RAID in a guest will use up some of the guest's CPU slice, and if you ever have CPU contention, it's going to kill the disk performance of that guest.

Second, problems with disk contention will be compounded by the fact that your Windows VM will be competing with (presumably) twice as many VMs at the host's logical disk level--one set of VMs for the host's logical disk 1, and another set of VMs for the host's logical disk 2. If one VM goes disk-hungry on either of the disks, your in-guest RAID1 performance is going to suffer. Granted, this can also happen if you RAID at the host level, but it will be more predictable then, and you can more easily figure out which guest to move to another set of disks. Doing RAID inside the guest means manageability will be horrible as you try to balance your other VMs so that they don't kill the performance of that in-guest RAID.

Third, if you're using expanding VMDKs (i.e., not preallocated), you're going to have to deal with different fragmentation patterns on the physical disks. One VMDK might be fragmented across a certain set of physical disk extents, while the other VMDK is fragmented across a different set of physical disk extents, because presumably different VMs' virtual disks span different physical disk extents. Take a simple example, where each letter is the name of a guest, and each letter+number is the start of a physical disk extent used by that VMDK:



Your in-guest mirror's disk performance is going to boil down to the worst of both physical disk layouts. On the flip side, the physical disk access patterns of your in-guest mirror will also impact the performance of the other guests on both disks. If you were to have the disks mirrored at the host level, the disk layout and fragmentation would be the same on both disks all the way down to the device, performance would be more predictable.

If you're unlucky enough to have both CPU contention and disk contention, the guest running your in-guest RAID1 is going to come to a grinding halt--not to mention, all the other guests that are competing for the same CPU slices and disk I/O.

So if you can't pony up for RAID at the host level, I would at least minimize the potential for disk contention by ensuring the physical disks are used solely by the single guest running RAID--in other words, don't let any other guests use those datastores. (You might even want to go so far as to add the RAW disks to the guest instead of using VMDKs.) That way, your only concern is CPU contention, which you should be able to manage more predictably.

share|improve this answer
2 different physical drives, 2 datastores, 100 % dedicated for this VM. And RDM is not an option for me in this case.. –  MatteS Aug 27 '10 at 21:03
@MatteS: Thanks for the clarification. In that case, I'd expect a slight performance hit from doing the software RAID inside the guest and from using VMDKs instead of RDM, but you may not notice, especially if you're already migrating from slower hardware. In your case, I think the fault tolerance would be worth the small loss in performance if you don't have fault tolerance at the host level. –  rob Aug 27 '10 at 22:00
Thanks for your input. I could do hardware raid (motherboard has that feature), but I have no way to monitor if a drive fails, since ESXi doesnt have drivers for that hardware. But thats another question entirely... –  MatteS Aug 28 '10 at 12:33

What benefits do you think it would give you? Will both of the virtual disks be stored on the same SAN/physical drives?

If they virtual dists are on the same physical drives there really isn't any benefit from a reliability stand point, and it will decrease performance.

share|improve this answer
Different physical drives... –  MatteS Aug 27 '10 at 21:02

Performance shouldn't be dramatically worse than if you were to present the same disks natively. It's not something I'd choose to do in general but if you don't have the option of a good hardware RAID then I don't see why not.

That's assuming the two VMDK's are stored on two separate physical disks. If the two VMDK's are on a single datastore then there's not much point.

From a scalability POV you can use this approach to get past VMware's 2TB VMDK limit - which does address one of your other questions, this is a more scalable solution in the sense that in can be used to enable volumes >2TB within Windows but not with just two disks unless you are thinking about RAID 0 which I wouldn't.

From a fault tolerance point of view again it depends on the scenario. If you only have single disks underneath your VMware Datastores then this is more Fault Tolerant but in general you shouldn't have such fragile Datastores if you can help it at all.

As far as manageability is concerned it's no big deal on a small scale.

share|improve this answer

Your Answer


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