As mentioned in a previous blog (ESXi), we have purchased additional hardware for our development environment. We have been using VMware Server for our existing hardware but wanted to go with a bare-metal hypervisor as this is more efficient for running VM’s (Virtual Machine) than running VMware Server.
The 2 options we have been looking at are:
- VMware ESXi 4.0
- Citrix XenServer 5.6
One of the important criteria for choosing, was an easy conversion path from our current VM’s (using VMware Server) to the new solution.
VMware ESXi 4.0.
The natural choice was to go with VMware ESXi 4.0 as an upgrade to VMware Server. The installation and configuration was easy and we successfully converted our existing VM’s to ESXi using the Converter Standalone Client . We installed ESXi on a USB stick which can then be used to boot the server to run ESXi. This gives the ability to clone the USB stick for DR and backup purposes.
The management console using vSphere Client is also easy to use, although some features are hidden away and take some time to find (ie. uploading and downloading files to the datastore). With vSphere Client you get a nice overview of the VM’s and the resources used by each VM.
We were all set to go with deploying VMware ESXi on our hardware and the last step was checking the security and tightening the security of ESXi. We deploy some of our servers on public facing networks and as such we need to be very careful about security and we have some strict policies around security.
This is where ESXi was not secure enough for us. It is not possible to change any of the default ESXi ports used by the management console and it is also not possible to run a firewall service on ESXi. The operating system that runs on the host, is a cut down Linux version with limited possibilities for any configuration changes and additions. This also makes it difficult to use standard methods for VM backups such as rsync and scp.
VMware states that the ESXi management console interface should not be on a public network, and/or should have a firewall in front of it. Having a firewall in front is still not secure enough for us, we want the ability to change the default ports that the management console communicates on, otherwise those ports will still get hammered even if they are behind a firewall. With our configuration it would be possible to have the management console on a private internal network and have one of the VM’s connect to this private network. This is a bit of a chicken and egg situation where the VM has to be running in order to manage the VM’s. Not an ideal situation for us.
Citrix XenServer 5.6
The other option was to try Citrix XenServer. We had a few issues installing XenServer on a USB stick. Turns out a 16GB USB stick needs to be used, smaller sizes are possible but require tweaking on the install scripts.
XenServer is a nice solution and the XenServer management Console called XenCenter is great. With XenServer you get a full blown Linux operating system allowing you to to secure the host and do regular VM backups.
XenServer works quite differently to ESXi, and although not being experts in this area, we understand it as follows: XenServer is more “bare bones” than ESXi. The VM’s on XenServer talk more directly to the hardware whereas with ESXi there is more of an abstraction layer. The advantage for XenServer is that it runs the VM’s faster and more efficient than ESXi. The downside is that each OS has to be certified to run as a VM in XenServer as it has to talk directly to the hardware and specific drivers have to be build. This means each new release of Linux has to be certified against XenServer before being able to create a VM for that specific OS. With ESXi (and other VMware solutions), the VM uses generic VMware drivers so the OS is not so crucial. For example, we are running Solaris x86 and older versions of Linux in VMware Server.
To convert our existing VMware Server VM’s to XenServer, we use Citrix XenConvert. We first imported the VM’s to ESXi and then exported the VM’s out of ESXi using the Open Virtualization Format (OVF) and then converted it to XenServer. That was where we started to have issues with XenServer.
If the VM had only one virtual disk, then the conversion was fine, but as soon as the VM had more than one virtual disk the conversion was not successful. With a lot of tweaking we may have been able to improve the conversion but our VM’s are quite complicated systems and we did not want to find out three months down the track that one of the components in our VM was not working due to a conversion error.
The MS Windows server VM that we had converted to XenServer also required new activation because Windows detected a significant change in the underlying hardware.
Also the limited ability to only run specific OS as VM’s was also a limiting factor for XenServer. Our software Dbvisit runs on many different platforms and we need to be able to test on all of them.
Conclusion
What did we decide in the end to use? Who is the winner between VMware ESXi versus XenServer?
We have gone back to using VMware Server. While there is a performance penalty, you can install the OS of your choice and harden it as much as you like.
ESXi 4.0 is not secure enough for our configuration and it was too difficult to convert our existing VM’s to XenServer.
Had we started out from scratch and did not have any existing VM’s, then the clear winner would be XenServer for us.
