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.


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.


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.


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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Under Features you say: "It also allows for high availability, if a box fails you can easily migrate the containers over to a new host."

I wonder how is it possible to migrate containers from the failed box if it just have failed?

Failed Box Migration

DRBD is included with the current release of Proxmox. Using that you are able to easily migrate the box over because the data has already been moved. DRBD has largely been a manual un-documented process to get going in Proxmox. The next release of Proxmox promises to fix that and change the storage model around to make doing things like that much easier.

/-\ ndrew


i using proxmox VE and for now i don`t have problems, i succesful setup centos, ubuntu, gentoo, freebsd and windows 2003/2008 ...

Viva Virtual Guests

Proxmox VE - our open source virtualization platform - is used worldwide on over 10.000 physical servers - each one is running a lot of virtual guest systems.

bodhi.zazen's picture

Nice write-up kaptk2

I took Proxmox for a spin and I would like to add a few comments.

One caution, the installer asks minimal questions and the installation takes over the entire hard drive (no option to select an existing partition). Proxmox uses LVM so resizing post install is not as simple as firing up gparted ...

There is no option to set a user name or root password during the installation (I found the root password here : http://pve.proxmox.com/wiki/Installation ).

Otherwise Proxmox seems nice, all hardware working out of the box (well, no X of course, lol).

Scott Dowdle's picture

Resizing LVM

Resizing LVM is actually pretty easy... but yeah... I don't do it often enough from the command line so I have to look it up when I do do it. Basically you use the lvm command with the lvresize parameter. Here's an example:

lvm lvresize /dev/VolGroup00/LogVol01 -L +256M

I'm not sure about Proxmox VE or Ubuntu but Red Hat has a pretty nice GUI LVM management app named system-config-lvm. Red Hat covers it in their Deployment Guide.

I would guess that using LVM has some advantages when it comes to backups via LVM snapshots.

I gave Proxmox VE a try only yesterday by installing it on two machines and setup one OpenVZ container and one KVM machine (Windows XP Pro). I hope to write up my findings as well... when I have more time.

bodhi.zazen's picture


Resizing is not *too* bad.

You need to also resize the file system via resize2fs first, then resize the LVM (logical first, then physical volume).

The biggest problem with resizing LVM is that the LMV structure itself can become fragmented.

Scott Dowdle's picture

The nature of LVM

You are probably correct about having to resize the filesystem that resides on top of an LVM partition. I've only resized swap partitions from the command line and just redid the swap (mkswap).

On a number of occations I have resized LVM partitions with the previously mentioned system-config-lvm GUI tool. It has worked well and done both partition and filesystem resizing transparently so I didn't even notice that the filesystem part was actually a separate background operation.

Regarding your comment about fragmentation, that is true but the very nature of LVM means you can do things (in a fairly transparent manner) with it that you can't do without it. Namely you can manage physical drives with more functionality... being able to create larger drives / partitions than can fit on a physical drive... snapshots, etc.

The resize ability is a built in feature of LVM and (to the best of my knowledge) does not require rearranging partitions... whereas with partition utilities like Partition Magic, Partition Commander and parted... unless your freespace is located exactly where it needs to be... it has to reorganize partitions which can often be quite time consuming the larger the drive is. Having to rearrange the paritions makes it possible to have less fragmentation. LVM repartitioning (to a certain extent) can also be done online... although the filesystem resizing part usually requires that an active partition be umounted to be operated on.

I have to admit that my knowledge and expertise (or lack thereof) on filesystem management has come from mostly ad-hoc usage. I greatly appreciate your participation in this topic and encourage others to jump in as well. :)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.