The following is a list of hardware components that we will need to put together our first basic Proxmox cluster. If you already have some components you would like to use to set up your cluster, it is important to check if they will support virtualization. Not all hardware platforms support virtualization, especially if they are quite old. To get details on how to check your components, visit http://virt-tools.org/learning/check-hardware-virt/.

A quicker way to check is through the BIOS and look for one of the following settings in the BIOS option. Any one of the these should be Enabled in order for the hypervisor to work.

Download the software given in the following table in the ISO format from their respective URL, and then create a CD from the ISO images.

The next diagram is a network diagram of a basic Proxmox cluster. We will start with two node clusters with one shared storage setup with either Ubuntu or FreeNAS. The setup in the illustration is a guideline only. Depending on the level of experience, budget, and available hardware on hand, you can set up any way you see fit. Regardless of whatever setup you use, it should meet the following requirements:

This book is intended for beyond-beginner-level user and, therefore, full instruction of the hardware assembly process is not detailed here. After connecting all equipment together, it should resemble the following diagram:

Perform the following simple steps to install Proxmox VE on Proxmox nodes:

We are now going to create a Proxmox cluster with two Proxmox nodes we just installed. From admin PC, (Linux/Windows), log in to Proxmox node #1 (pmxvm01) through secure login. If the admin PC is Windows based, use program such as PuTTY to remotely log in to Proxmox node.

Linux users use the following command to securely log in to Proxmox node:

# ssh [email protected]

After logging in, it is now time to create our cluster. The command to create a Proxmox cluster is as follows:

# pvecm create <cluster_name>

This command can be executed on any of the Proxmox nodes but only once.

The cluster does not operate on master/slave basis, but on Quorum. In order to achieve healthy cluster status, all nodes need to be online. Let's execute the following command and create the cluster:

root@pmxvm01:~# pvecm create pmx-cluster

The preceding command will display the following messages on the screen as it creates a new cluster and activates it:

Restarting pve cluster filesystem: pve-cluster[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'
Starting cluster: 
  Checking if cluster has been disabled at boot. . . [  OK  ]
  Checking Network Manager. . . [  OK  ]
  Global setup. . . [  OK  ]
  Loading kernel modules. . . [  OK  ]
  Mounting configfs. . . [  OK  ]
  Starting cman. . . [  OK  ]
  Waiting for quorum. . . [  OK  ]
  Starting fenced. . . [  OK  ]
  Starting dlm_controld. . . [  OK  ]
  Tuning DLM kernel config. . . [  OK  ]
  Unfencing self. . . [  OK  ]
root@pmxvm01:~#

After cluster creation is complete, check its status by using the following command:

root@pmxvm01:~# pvecm status

The preceding command will display the following output:

Version: 6.2.0
Config Version: 1
Cluster Name: pmx-cluster
Cluster ID: 23732
Cluster Member: Yes
Cluster Generation: 4
Membership status: Cluster-Member
Nodes: 1
Expected votes: 1
Total votes: 1
Quorum: 1
Active subsystem: 5
Flags:
Ports Bound: 0
Node name: pxvm01
Node ID: 1
Multicast addresses: 239.192.92.17
Node addresses: 192.168.145.1
root@pmxvm01:~#

The status shows some vital information that is needed to see how the cluster is doing and what the other member nodes of the cluster are. Although from Proxmox GUI we can visually see cluster health, command-line information gives a little bit more in-depth picture.

After the cluster has been created, the next step is to add Proxmox nodes into the cluster. Securely log in to the other node and run the following command:

root@pmxvm02:~# pvecm add 192.168.145.1

Verify that this node is now joined with the cluster with the following command:

root@pmxvm02:~# pvecm nodes

It should print the following node list that are member of the cluster we have just created:

Node   Sts   Inc    Joined                  Name
   1   M    4900    2014-01-26 16:02:34     pmxvm01
   2   M    4774    2014-01-26 16:12:19     pmxvm02

The next step is to log in to Proxmox Web GUI to see the cluster and attach shared storage. Use the URL in the following format from a browser on the admin computer to access the Proxmox graphical user interface:

https://<ip_proxmox_node>:8006

The cluster should look similar to the following screenshot:

On a clean installed Proxmox node, a paid subscription-based repository is enabled by default. When you log in to the Proxmox GUI, the following message will pop up on entering login information:

If you want to continue using Proxmox without subscription, perform the following steps to remove the enterprise repository and enable a subscription-less repository. This needs to be done on all Proxmox nodes in the cluster.

A Proxmox cluster can function with local storage just fine. But shared storage has many advantages over local storage, especially when we throw migration and disaster-related downtime in the mix. Live migration while a virtual machine is powered on is not possible without shared storage. We will start our journey into Proxmox with NFS/iSCSI shared storage, such as Ubuntu or FreeNAS.

After you have the choice of shared storage server setup, attach the storage with Proxmox by navigating to Datacenter | Storage. There should be three shares as shown in the following table:

After setting up both the NFS and iSCSI shares, the Proxmox GUI should look like the following screenshot:

With our cluster up and running, it is time to add some virtual machines to it. Click on Create VM to start a KVM virtual machine creation process. The option window to create a virtual machine looks like the following screenshot:

Creating an OpenVZ virtual machine

Now we will create one OpenVZ/container virtual machine. OpenVZ is container-based virtualization for Linux where all containers share the base host operating system. At this moment, only the Linux OpenVZ virtual machine is possible, and no Windows-based container. Although OpenVZ containers act as independent virtual machines, they rely heavily on the underlying Linux kernel of the hypervisor. All containers in a cluster share the same Linux kernel of the same version. The biggest advantage of the OpenVZ container is soft memory allocation where memory not used in one container can be used by other containers. Since each container does not have its own full version of the operating system, the backup size of containers is much smaller than the KVM-based virtual machine. OpenVZ is a great option for an environment such as a web hosting provider, where many instances can run simultaneously to host client sites.

Tip

Go to http://openvz.org/Main_Page for more details on OpenVZ.

Unlike a KVM virtual machine, OpenVZ containers cannot be installed using an ISO image. Proxmox uses templates to create OpenVZ container virtual machines and comes with the very nice feature of templates repository. At the time of this writing, the repository has close to 400 templates ready to download through the Proxmox GUI.

Templates could also be user-created with specific configurations. Creating your own template can be a difficult task and usually requires extensive knowledge of the operating system. To take the difficulties out of the equation, Proxmox provides an excellent script called Debian Appliance Builder (DAB) to create OpenVZ templates. Visit the following links before undertaking OpenVZ templates:

• http://wiki.openvz.org/Category:Templates

• http://pve.proxmox.com/wiki/Debian_Appliance_Builder

From the Proxmox GUI, click on the Templates button as shown in the following screenshot to open the built-in template browser dialog box and to download templates:

For our OpenVZ virtual machine lesson, we will be using the Ubuntu 12.04 template under Section: system as shown in the following screenshot:

Create the OpenVZ container using the following specifications:

OpenVZ creation tab	Specification	Selection
General	Node	pxvm01
	Virtual machine ID	121
	Virtual machine hostname	ubuntuCT-01
	Storage	vm-nfs-01
	Password	any
Template	Storage	ISO-nfs-01
	Template	ubuntu-12.04-standard
Resources	Memory	1024 MB
	Swap	512 MB
	Disk size (GB)	30
	CPUs	1
Network	Bridged mode	vmbr0

Tip

OpenVZ containers cannot be cloned for mass deployment. If such mass deployment is required, then the container can be backed up and restored with different VM IDs as many times as required.

With all three of the virtual machines created, the Proxmox cluster GUI should look like the following screenshot:

One of the great features of Proxmox is the ability to clone a virtual machine for mass deployment. It saves an enormous amount of time while deploying virtual machines with similar operating systems.

Introducing cloning using a template

It is entirely possible to clone a virtual machine without ever creating a template. The main advantage of creating a template is virtual machine organizing within the cluster.

Tip

The template for cloning is not the same as the template required to create OpenVZ/container.

A template has a distinct icon as seen in the following screenshot, which easily identifies it from a standard virtual machine. Just create a VM with desired configuration, and then by the touch of a mouse click, turn the VM into a template. Whenever a new VM is required, just clone the template.

For a small cluster with few virtual machines, it is not an issue. But an enterprise cluster with hundreds, if not thousands, of virtual machines, finding the right template can become a tedious task. By right-clicking on a VM, you can pull up a context menu, which shows the option related to that VM.

Menu item	Function
Start	Starts virtual machine.
Migrate	Allow online/offline migration of virtual machine.
Shutdown	Safely powers down virtual machine.
Stop	Powers down virtual machine immediately. Might cause data loss. Similar to holding down the Power button for 6 seconds on a physical machine.
Clone	Clones virtual machine.
Convert to Template	Transforms a virtual machine into a template for cloning. Templates themselves cannot be used as a regular virtual machine.
Console	Opens a virtual machine in a VNC console.

Cloning using a template

The template is now ready for cloning. Right-clicking on the template will open up the context menu, which will have only two menu options: Migrate and Clone. Click on Clone to open the template cloning option window as shown in the following screenshot:

The most important option to notice in this menu is the Mode option. A clone can be created from a template using either Full Clone or Linked Clone.

Full Clone versus Linked Clone

The following is a comparison table with features of Full Clone and Linked Clone:

Full clone	Linked clone
Fully independent from original VM/template	Linked with original VM/template it was created from
Takes the same amount of disk space as original VM/template	Takes less disk space than original VM/template
Supported file types: raw, qcow2, and vmdk in LVM, NFS or iSCSI	Does not support storage file in lvm and iSCSI
If original VM/template is lost or damaged, the cloned VM stays intact	If original VM/template is lost, the cloned VM can no longer function. All linked VMs are connected to original VM/template
Full Clone has greater performance over Linked Clone	Performance degrades in Linked VM as more people share the same original VM/template
Full Clone takes much longer to create	Linked Clone can be created within minutes
Full Clone is a replica of the original	Linked Clone is created from a snapshot of original VM/template

From the previous table, we can see that both Full Clone and Linked Clone have pros and cons. One rule of thumb is that if performance is the main focus, go with Full Clone. If storage space conservation is the focus, then go with Linked Clone.

Tip

Attention: a damaged original VM/template can render all linked VMs unusable!

Proxmox migration allows a VM or OpenVZ container to be moved to a Proxmox node in both offline and online modes. The most common scenario of VM migration is when a Proxmox node needs a reboot due to a major kernel update. Without the migration option, each reboot would be very difficult for an administrator as all the running VMs have to be stopped first before reboot occurs, which will cause major downtime in a mission-critical virtual environment.

With the migration option, a running VM can be moved to another node without a single downtime. During live migration, VM does not experience any major slowdown. After the node reboots, simply migrate the VMs back to the original node. Any offline VMs can also be moved with ease.

Proxmox takes a very minimalistic approach to the migration process. Just select the destination node and online/offline check box. Then hit the Migrate button to get the migration process started. Depending on the size of virtual drive and allocated memory of the VM, the entire migration process time can vary.