Overview of Proxmox VE

Proxmox VE is an example of the end product being greater than the sum of parts. All the technologies used to build Proxmox VE are not unique however putting them all together and adding a nice interface is. Overall I am very impressed with the ease of use and quality of the software. The flexibility that is provided by virtualization plus the ease of administration provided by Proxmox VE is a great combination for anybody looking to use virtualization.

Introduction to Proxmox VE

Proxmox VE is virtualization platform based on Debian Etch x86_64. It comes as a self contained ISO installer, just pop the CD in on supported hardware and it installs automatically. Because of this it will only run of 64-bit machines. That makes testing out a Proxmox server impossible on older hardware.

From the Proxmox wiki one of the goals of the Proxmox project is to "Setup a complete virtual server infrastructure within 1 hour". It seems to achieve this goal as a base install and configuration takes about 30 minutes to complete. The install was smooth and only a few tweaks had to be done after the default install to get the server working as I wanted it. Common things like changing the root password, securing ssh, changing the ntp server and some other minor tweaks.

Features

One things that makes Proxmox unique is the ability to use OpenVZ containers and KVM virtual machines on the same server and manage both from a web interface. The web interface allows for easy creation, migration and manipulation of containers. In addition to the web interface you can use the command line to preform any functions that the web interface does not provide.

Another unique feature is the ability to "cluster" Proxmox boxes. Clustering allows for migration between the boxes as well as centralized management for the cluster. For example you have one master box that you can use to create containers on one of the other cluster slave boxes. The ability to do this allows the system administrator to quickly grow capacity with almost no downtime. It also allows for high availability, if a box fails you can easily migrate the containers over to a new host.

Drawbacks

The biggest drawback is the KVM code maturity. The KVM code is relatively young and may not be ready for full production use. I have yet to discover any serious trouble but your mileage may vary.

Another drawback is some web interface bugs. A few that I have come across are uploading OpenVZ templates does not work via the web interface with Firefox. You are required to do it "manually" using SCP or something similar. Another is there is no ability to change the description of uploaded OpenVZ templates. The last bug that I came across was a large bug with the web interface that makes the software feel unpolished. The web interface boasts the ability to preform backups from it. This feature is broken along with the ability to do live migrations the option to do it is there. I would have just left that page out and added it in when the ability to use the feature is available. None of these bugs are major and all are planned to be fixed in the next version.

Case Study 1

Windows 2003 server to KVM

One of my goals for this project was to get away from licensing XenSource for the few windows servers that we take care of. This would allow us to administer fewer servers as we would not have to maintain a separate "cluster" for Windows boxes running on XenSource.

The box that we migrated as a test was a production Windows 2003 server running MS-SQL and IIS.

Steps taken:
First I made sure that the operating system that I was migrating was compatible with KVM. Then I used VMWare converter (free download) to convert the Windows Server to a VMWare image. I then converted that file to qcow2 format using qemu-img convert (installed by Proxmox). Next I created a KVM container with close to the same parameters of the box that I am migrating. I then edited the file that was created to point to the qcow2 file created in the previous step. This procedure will work both with physical servers as well as virtual ones and though untested it should work with Linux hosts also. One thing to be aware of with Windows hosts is that if the Windows box to be migrated uses SATA or SCSI it will fail to boot. You need to enable an IDE driver in the registry. You may also want to look at installing Paravirtualized Network Drivers for Windows to increase network performance.

Case Study 2

OpenVZ to Proxmox

Since Proxmox runs OpenVZ migration of existing hosts is a snap using vzmigrate. After you migrate the container to Proxmox all that is left is to edit the container configuration file and change the ORIGIN_SAMPLE to say ORIGIN_SAMPLE="pve.auto". Now you will be able manage resource settings from the Proxmox web interface.

Conclusion

If the hardware is available to run Proxmox and you have a need for virtualization Proxmox is a good choice overall. A word of warning; while a web interface makes things easy to complete it is still important to have an understating of the underlying technology to keep yourself out of trouble.