This is a short overview of the key differences between OpenVZ and Xen that you might consider when choosing a VPS. Note that this article is based on my opinions and that you must do your own research to determine which, if either, technology is best for you and your application.

First, some terminology. OpenVZ isn't fully virtualized and could be more properly referred to as a 'container', not a VPS. That shouldn't affect your choice. It's the technical differences that matter.

Cheap VPS offers are everywhere lately, it seems. However, upon closer inspection I saw that almost all of the low-priced offers were for OpenVZ. While both Xen and OpenVZ offer their advantages, I chose Xen. So, there's my first bias, right up front. :)

OpenVZ advantages:

You'll notice I left price out of the above comparison. In theory, there should be a small price advantage for OpenVZ. I don't know how big it should be but it pertains to two things: 1) Xen uses more memory due to each VPS having its own kernel, and 2) Xen uses more CPU, also due to the additional software layer required to virtualize the kernel.

In practice, however, the price gap appears larger than the above technical differences suggest it should be. I think the remainder of OpenVZ's price advantage is based on 1) the ability for a vendor to easily oversell OpenVZ, and 2) The price competition that results from some vendors overselling OpenVZ.

OpenVZ doesn't encapsulate its containers into a fixed amount of memory, so it runs processes in the host environment to monitor memory usage and kill processes as a container allocates more than its assigned amount.

As a result of this difference, loading down an OpenVZ container is problematic. To partially offset this disadvantage, most OpenVZ vendors offer 'burst' memory in addition to 'dedicated' memory. That is, the monitor process is set to allow the container to use more than its allocated memory -- for a short period of time. This messy situation results in a potentially unreliable environment as some of your processes may be arbitrarily killed -- at the busiest times.

Xen, on the other hand, allows the use of a swap space and excess memory allocation results in (hopefully) idle segments being rolled out to the swap area. While this is good for the memory-hungry VPS user, it can consume significant I/O capacity when memory is overallocated to the point of busy segments getting swapped out. This is bad for everyone sharing the underlying hardware.

I see Xen as clearly the superior technology. A Xen VPS feels and behaves more like a dedicated server. However, I still would have purchased OpenVZ at some price difference. After a bit of research, however, I located Xen VPS's at practically the same price as the cheapest OpenVZ containers. That made my decision easy.

With that said, keep in mind that a bad hosting vendor can ruin either technology through various means. Both technologies share the disk drives and I/O paths as well as the processor cores. Hardware can be poorly configured and managed in any case. A reputable vendor is probably the single most important consideration in choosing a virtual server.

Lastly, carefully check the 'allowed use' policy. Make sure your application is allowed on the server you intend to purchase. Note that due to their different characteristics, the allowed use policy may differ between OpenVZ and Xen for the same host. Also, it's good to understand the memory usage characteristics of your applications. If you know how much memory/swap they require on a physical system, it'll probably work with that same amount of memory/swap on Xen.

[I'll post a review shortly of my current VPS vendor and I will then add a link to that article here.]