VirtualBox stability and making the switch

[ProVega]

I am new to VirtualBox and have only been following the project for about 2 months. I am working to move our divisions standard development environment from VPC 2007 SP1 over to VirtualBox for about 80 developers. Prior to making the move, we evaluated Virtual PC 7, Hyper-V, VMWare, VirtualBox and others. We ended up going with VirtualBox mainly because of the features, performance, the cost and the active community around it. That's the good news.

Now the not so good news, to date, I have been pretty disappointed with the overall stability of the product. In the 3 or so weeks the team has switched over, we have a bunch of problems relating to mouse integration not working, crashes related to hardware virtualization and USB support not working. These are all things that we can live with, they are items being tracked and fixed in newer releases and can be worked around. What is disturbing to me though are overall crashes that result in VHD corruption. We have had at least 4 incidents where the VHD were corrupted with errors related to INVALID HEADER and the drive was simply not recoverable and 2 Host OS Blue Screens of Death. On top of this of this, I am concerned by the amount of change taken per release and thus the possible regressions caused by these changes.

So here are my humble asks of the community

1.) Are other teams using Virtual Box in enterprise mission critical environments and are their any recommendations / best practices therein?
2.) Are regressions typical on the Virtual Box project, with the number of changes be taken? Is there an overall stability plan?
3.) Are there tools (I looked at the covert to raw and other internal commands) to repair and recover broken VHD images. (I also tried WinImage, VMWare Convert and VirtualPC).

Thank you very much for your responses and I very much appreciate this project and the hard work of all those involved.

[vbox4me2]

Stick with a stable version (do your own tests to find out which is stable for you).
Stick with a stable Host, ea. don't let a Host get clutered like having vmware and vbox on the same Host, they can coexist but only when the user knows how to do this properly.
Don't use vhd, stick to or convert to VDI.
Consider using immutable VDI's.

[ProVega]

Are VDI's inherently more stable than VHDs under VirtualBox? If so, I can convert it. It would be nice if there was a "repair header" or something. Interesting ideal about immutable disks, in this case though it is the SnapShots that were corrupted.

Also, I don't have VMware on my box, but I do have VirtualPC 2007 SP1, does it have the same conflicts with VirtualBox?

Finally, any thoughts on regressions and the amount of changes taken from build to build? It would be nice to see a "stabilization fork" or something with less changes and more focus on stability.

Thank you for the reply!

[AntiMatter]

1.) Are other teams using Virtual Box in enterprise mission critical environments and are their any recommendations / best practices therein?
2.) Are regressions typical on the Virtual Box project, with the number of changes be taken? Is there an overall stability plan?
3.) Are there tools (I looked at the covert to raw and other internal commands) to repair and recover broken VHD images. (I also tried WinImage, VMWare Convert and VirtualPC).

I am in similar situation, our company policy is VMWare ESX. However, I have evaluated VirtualBox since almost a year and have officially succeeded to convince my team to convert to VirtualBox a week ago. They are DEV VMs using various Windows as Guest OS that we can afford to run in Workstation mode independently of the company VWMare ESX server. Previously we ran these DEV VMs using VMWare Server 1.x and VMWare Workstation 6.5. Here are the main hints I hope will save you some times:

1- Virtual PC 2007 has low performance. We gave it up very quickly.

2- Image conversion yields unreliable results. Physical to virtual are usually slow. Conversion VWWare VMDK to VirtualBox VDI is even worse, I have never succeeded to go further than the login screen. Recently our infrastructure team had converted two physical Windows 2003 64 bits to VMWare image to run them under ESX, the performance is bad, these P2V VMs are a pain to use. May be in the future the conversion will be more reliable, for now, I don't trust image conversion.

3- As a consequence, I rebuild all the VMs from scratch for Virtualbox. Take care VDI disk size is immutable, if your guest are Windows 2008 or Win7, give at least 50 GB in size. The VM rebuild is a lengthy process (system, dev tools, configuration, unit tests). The bright side is that the system is brand new, perfectly up to date and all the useless stuffs nobody knows about are all removed. In the process, this also allowed us to review and improve our config and unit tests. Case in point: I spent 3 days to rebuild our new DEV VM. It works rock solid, consumes less RAM and the team members told me VM run roughly 30% faster. Another team, who took the shortcut, instead of building new VM, they did a Physical to Virtual (for ESX). They spent now a WEEK, patching, re-patching and the machine still sucks.

4- After successful unit tests. I cloned one VM for a developer and gathered feedbacks. Then I re-iterate a 2nd time with a 2nd developer. These two trials were enough. The important point is: the guys won't spend any time to learn or customize the VM. To have the new Virtualbox easily adopted, it has to be click and play. Which means I customize in advance (change SID, join domain, configure apps, etc.). Then I have them install Virtualbox 3.04 showed a few settings, and then they started using the VM right away.

5- VirtualBox 3.04 currently is pretty OK. One annoying bug is the Blue screen on warm reboot if you configure the VM to use SATA. I have also seen some other blue screens with 3.06beta. But overall, these bugs are not show-stoppers.

6- After a few weeks, when the users get confident I show more advanced tricks. And progressively I have to get the team create their own VMs. Because I believe the PUEL license stipulates somewhere that Virtualbox is free but the user has to create his/her own VM. Actually, I am not very clear about this licensing details. I hope someone will jumps in and clarify the matter. One thing I am quite sure is that if there is anywhere a veil of possibility that we could be in violation of license agreement, then we have no other choice than going back to VMWare which is the company official VM solution. This would be too bad. I took me a year to "sell" Virtualbox to the team. If we leave VBX now, it will have no second chance.

Good lucks for your Virtualbox migration.