Book Image

Mastering Proxmox - Third Edition

By : Wasim Ahmed
Book Image

Mastering Proxmox - Third Edition

By: Wasim Ahmed

Overview of this book

Proxmox is an open source server virtualization solution that has enterprise-class features for managing virtual machines, for storage, and to virtualize both Linux and Windows application workloads. You'll begin with a refresher on the advanced installation features and the Proxmox GUI to familiarize yourself with the Proxmox VE hypervisor. Then, you'll move on to explore Proxmox under the hood, focusing on storage systems, such as Ceph, used with Proxmox. Moving on, you'll learn to manage KVM virtual machines, deploy Linux containers fast, and see how networking is handled in Proxmox. You'll also learn how to protect a cluster or a VM with a firewall and explore the new high availability features introduced in Proxmox VE 5.0. Next, you'll dive deeper into the backup/restore strategy and see how to properly update and upgrade a Proxmox node. Later, you'll learn how to monitor a Proxmox cluster and all of its components using Zabbix. Finally, you'll discover how to recover Promox from disaster strikes through some real-world examples. By the end of the book, you'll be an expert at making Proxmox work in production environments with minimal downtime.
Table of Contents (23 chapters)
Title Page
Credits
About the Author
About the Reviewers
www.PacktPub.com
Customer Feedback
Preface

Virtual machine replication


Virtual machine replication is a brand new feature that has been added from the Proxmox VE 5.0 release. This is a very useful feature for a single-node Proxmox environment where VM disk images reside locally on the same computer node the VMs actually run from. With this option, VMs can be replicated to a different node in real time should the primary node go down for any number of reasons. In such a scenario, the second node with a replica of the VMs can be brought online, thus minimizing downtime significantly.

Note

It is very important to note here that this replication will only work when the VM disk image is stored on a local ZFS storage.

The storage must be attached to a Proxmox cluster using the ZFS storage plugin, as shown in the following screenshot:

The replication simply will not work when the disk image is on any other storage. Even if the disk image is stored on a ZFS storage with NFS share, replication will not work. In such a scenario, when trying to create replication, the following error message will be displayed:

ZFS is needed because the replication uses ZFS snapshots to perform replication, minimizing network traffic. A new command line tool, pvesr, has been added to perform all replication tasks. When we manage replication through the GUI, it just leverages the pvesr command. 

Note

It should be noted here that the replication feature is presented as a technology preview in Proxmox 5.0, but from our extensive lab testing, it has proven very stable. If you have a single-node Proxmox deployment and want to use replication as a primary backup strategy, then doing tests to familiarize yourself with the replication process is highly recommended.

Creating a replication task through the GUI

The replication menu is accessible from Datacenter-, node-, and VM-specific menus. The only difference is each replication menu shows the specific entity-related replication tasks. For example, the Datacenter-specific replication menu shows all replication tasks within the cluster, whereas the node-specific replication menu shows replication tasks for that node only. 

To access the replication dialog box through the Proxmox GUI, select a VM you want to replicate; then, from the Replication option, click on Add, as shown in the following screenshot:

Since we are creating a replicated version of the VM, we cannot define any manual ID for the VM. The replicated VM is going to be an exact copy of the existing VM, including the same ID and identical configuration.

Target

This is a drop-down list to select which Proxmox node the VM is going to be replicated to. Note that the destination node must also have ZFS storage set up. If the source VM is on ZFS but the destination node has no ZFS storage, we cannot create the replication task. We will see an error message, as shown in the earlier section. It is possible to replicate a VM to multiple nodes, thus increasing redundancy. We can achieve this by creating multiple tasks for the VM, but we can never replicate a VM to the same storage or same node the VM is in. 

Schedule

Here, we define how frequently the VM will be replicated. Initially, when a replication task is started, the process will replicate the entire VM; after that, it will only replicate incrementally on set intervals. The drop-down list has some predefined schedules, which can be also customized, simply by typing the value. For example, if we want to replicate the VM every 5 minutes, we can simply type */5 in the schedule textbox, since there is no predefined schedule for 5 minutes. Note that frequent replication will increase bandwidth consumption, depending on how much data is changing in the VM.

Rate limit (MB/s)

We can limit the amount of bandwidth that can be consumed during the replication process. By default, it is set to unlimited bandwidth. When replicating multiple VMs on the node, it may be very helpful to limit the rate so the running VMs can be used without any issue. The rate limit is defined in MBps.

Enabled

To enable the replication task, this option needs to be checked. This is useful when disabling the replication task temporarily. To enable it again, simply select the task and click on the Edit button.

Creating a replication task through the CLI

In order to create a replication task through the CLI, it is very important to know that each replication task created must have a cluster-wide unique ID. When the tasks are created through the GUI, the ID gets created and assigned automatically. But when they are created through the CLI, we have to manually assign the ID. This unique job ID is node-specific only. For example, if the first node has a replication task using a job ID from 0 to 10, another node can also have unique job ID of the same sequence. The format of this ID is:

<vmid>-<integer job number>

We are going to use the pvesr command to create a replication task. The following is the command-line format to create a task:

# pvesr create-local-job <vmid>-<job number> <destination_node> --schedule "<frequency>" --rate <limit in MB/s>

Using the command-line format, if we want to create a replication task for VM #100 to replicate to node pmx-02 every 5 minutes with a rate limit of 20 MBps, we will enter the following command:

# pvesr create-local-job 100-0 pmx-02 --schedule "*/5" --rate 20

If we want to create another task for VM #102 to node pmx-02 every 30 minutes without a rate limit, we will enter the following command:

# pvesr create-local-job 102-1 pmx-02 --schedule "*/30"

Note that we have entered a unique ID of 1 for this task, for VM #102.

Once the task is created, we can also edit it through the CLI. The following command format is to update an already created replication task:

# pvesr update <vmid>-<job number> --schedule "<frequency>"

To change the schedule of replication 100-0 to half an hour, we would enter the following command:

# pvesr update 100-0 --schedule "*/30"

To see a list of all replication tasks, use the following command format:

# pvesr list

To disable or enable a replication task, use the following command format:

# pvesr <disable/enable> <vmid>-<job number>

Replication process

The replication process will start automatically, at set intervals, without any user interaction. If the replication task is created for a VM for the first time, it will initially send an entire copy of the VM to the destination node. Once the initial transfer is done, then the replication process will only send new data that has changed incrementally.

Also, after the initial transfer, we are now fully ready with VM redundancy. In the event the node with the running VM goes down, we can simply turn on the replicated VM on the second node while we fix the issue on the primary node. This can significantly decrease the downtime for a small environment without shared storage. Depending on what replication interval has been used, users will only lose data since the last sync. So if the scheduled task is set to run every 5 minutes, then the replicated VM will only lose the last 5 minutes.

Replication depends on SSH, so it is important that nodes can connect to each other with proper SSH keys. If there is a problem with SSH connectivity, you may see a replication error like the following:

You may have to find the cause of the SSH issue, but in most cases it can be fixed using the following command:

# ssh-copy-id <proxmox_Node>

To run a replication task manually at any time, select the replication task, then click on the Schedule now button on the Task page.