Over the weekend, I began to move my home cloud system over from OpenVZ to XenServer. I thought that I should chronicle a few lessons learned here. Some of this information is just not available on the Internet and some of it are my personal opinions about the pros and cons of the two different virtualisation platforms.
The initial installation for both OpenVZ and XenServer was pretty straight-forward. For XenServer, both the base ISO and Linux additional ISO were needed during installation. Fortunately, they can both be burned on the same CD-RW, one at a time and used one after the other. So, there is no need to use two blank CDs to install it.
However, the two platforms could not be more different when it came to configuring the systems. I was totally lost in XenServer because it is quite different from using a regular Linux system. There were a lot of very new concepts that I had to quickly pick-up. For example, everything needed to be identified by UUID because there is no other easy way to do it. Xen abstracts everything away so that it can be managed automatically without too much user intervention.
Lost in Lenny
I needed to run Debian Lenny as the guest OS for all my cloud servers. In OpenVZ, all that was needed was to download the Lenny template and generate a new server with it. However, the Lenny template on XenServer does not produce a running system but instead, runs a net-install.
At first, I tried to follow the instructions given on the Xen website to download and build a Lenny installation ISO to be used to install Xen. However, it turns out that it is much faster to just do a basic net-install over the Internet than to download and use an installation DVD. So, that was the path I took instead. Since I have a local apt-mirror running, it was a breeze to install and generate a number of different templates.
I do not understand why Xen did not ship with a bunch of Debian templates. It ships with a whole bunch of other templates. I managed to generate three templates corresponding to the popular VPS packages offered online – 64MB, 128MB and 256MB. I will try to share my pre-generated templates once I figure out how to get that done.
Size is Relative
I learned that 64MB is not actually 64MB in both OpenVZ and XenServer. Due to the way that these technologies emulate memory, they perform very differently under different circumstances. This is very obvious in low memory configurations. I could barely run any services on a 64MB OpenVZ server but I could run a whole bunch of services on a 64MB Xen server.
After doing some reading, it all comes down to how memory is allocated and committed by each technology. I might be wrong but it turns out that when an application asks for memory on OpenVZ, that memory is reserved for it. However, on Xen that memory is only reserved when the application uses the memory.
After my initial toying around, I would have to say that Xen seems more like an enterprise product while OpenVZ is not so much. In the year that I have been using OpenVZ, I managed the guest servers as if they were parts of the host server. However, in Xen, I am forced to treat each guest server as its own server. In fact, technically, the Dom0 and DomU Xen domains are technically peers.
Overall, I am quite happy to say that I have a very good impression of Xen and I will continue to use it for all my future cloud needs.