ADVENTOS Blog

OpenNebula: Erstellen von Snapshots mit Ceph als Storage-System



 

Beim Versuch, unter ONe ein Snapshot von einer VM zu erstellen, erscheint im Log, dass das Format raw für VM-Snapshots nicht kompatibel sei, obwohl die Images als qcow2 angelegt wurden. Dieser Schein trügt, denn in der jeweiligen Datei mit den Eigenschaften einer VM steht, dass das Image als raw vorliegt. Grund dafür ist, dass Ceph derzeit keine native Unterstützung für qcow2 enthält und somit alle Images automatisch als raw anlegt. Ein Snapshot ist unter der Verwendung von Ceph nur für Images und nicht für VMs möglich. Ein Rollback eines solchen Snapshots ist zudem nur im ausgeschalteten Zustand der VM möglich. Außerdem bietet ONe bisher keine Möglichkeit, einen scheduled task für Image-Snapshots zu erstellen. Eine Möglichkeit, sich dagegen Abhilfe zu verschaffen, wäre, ein (Ana)cron-Job (zeitgesteuerte Skripts unter Linux) mithilfe eines Shell-Skriptes zu erstellen. Die Programmierung eines solchen Skriptes erfordert zwar erweiterte Programmierkenntnisse, jedoch lassen sich so die Snapshot-Aufgaben sehr detailliert formulieren, da jegliche Tools des Betriebssystems zur Verfügung stehen. Z.B. lassen sich die Snapshots direkt auf ein externes Medium, wie einem NAS, als Image-Datei exportieren, um später wieder – auch in einem anderem Cluster – importiert zu werden. Hier ein Beispiel für ein solches Skript:

#!/bin/bash
# Create VM snapshots weekly

set -e

#Disk IDs must match VM IDs!
vmids=(1 2 3)       #space separated VM IDs
diskids=(0 1 0)     #space separated Disk IDs

if [ "${#vmids[@]}" != "${#diskids[@]}" ]
then
        echo "Disk IDs don't equal VM IDs! Aborting..."
        exit 1
fi

tmppath="/home/cephadmin"       #path to store Imagess before moving to destination path
destpath="/mnt/nas/vmbackups"   #final destination path
datenow=$(date +%Y%m%d)
for i in "${!vmids[@]}"; do     #walk through the array above
        vmexist=$(onevm list -l ID | grep ${vmids[$i]} | tr -s ' ')
        if [ -z $vmexist ] || [ ${vmids[$i]} != $vmexist ]      #check whether VM ID exists with given Disk ID
        then
                echo "VM with ID ${vmids[$i]} doesn't exist. Skipping..."
        else
                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                #ensure snapshot can or needs to be created
                if [ -z "$(onevm show ${vmids[$i]} | awk '/VM DISKS/' RS= | tail -n +2 | awk '{ print $1$2 }' | grep ${diskids[$i]}cephds)" ] || [ -n "$(oneimage list -x | grep ${vmids[$i]}-${diskids[$i]}-IMG$datenow)" ] || [ $vmstate == "unde" ]
                then
                        echo "VM ${vmids[$i]} not valid or necessary, skipping..."
                else
                        onevm disk-snapshot-create  ${vmids[$i]}  ${diskids[$i]} "Snap$datenow"
                        vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "snap" ]
                        do
                                sleep 1
                                echo "Waiting for snap to be created..."
                                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        imgout=$(onevm disk-saveas ${vmids[$i]}  ${diskids[$i]} "${vmids[$i]}-${diskids[$i]}-IMG$datenow")
                        vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "hotp" ]
                        do
                                sleep 1
                                echo "Waiting for image to be created..."
                                vmstate=$(onevm list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        imgid=$(echo $imgout | cut -d ' ' -f3)
                        imgstate=$(oneimage list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        while [ $vmstate == "lock" ]
                        do
                                sleep 1
                                echo "Waiting for image to get finished..."
                                imgstate=$(oneimage list -l ID,STAT | grep ${vmids[$i]} | tr -s ' ' | cut -d ' ' -f3)
                        done
                        qemu-img convert -f raw rbd:one/one-$imgid -O raw $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                        #copy to destination
                        cp $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw $destpath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                        #remove temporary file
                        rm -rf $tmppath/${vmids[$i]}-${diskids[$i]}-IMG$datenow.raw
                fi
        fi
done

exit 0

 

 


VM-Migration von Proxmox VE nach OpenNebula



Ziel

Die auf dem Proxmox VE betriebenen VMs sollen auf ein OpenNebula-Cluster migriert werden.

Vorgehensweise
Backup der Proxmox VE VMs

Zunächst müssen von den für die Migration vorgesehenen VMs jeweils ein Backup erstellt werden. Am einfachsten geschieht dies über die Weboberfläche des Proxmox VE. Dazu wird jeweils die VM ausgewählt und mittels der Backup-Schaltfläche (nicht Snapshot) an einem beliebigen Ort ein unkomprimiertes Backup erstellt. Dabei gilt es, ggf. den im Log angezeigten Pfad in die Zwischenablage zu kopieren.

Konvertierung des Backups

Nach Beendigung des Backupvorgangs ist die Kommandozeile des Proxmox VE zu öffnen - am besten via ssh. Hier ist folgender Befehl auszuführen:

vma extract BACKUP AUSGABE

Dabei ist BACKUP der Pfad aus der Zwischenablage (inkl. .vma-Endung) und AUSGABE das Verzeichnis, in das die konvertierte VM abgelegt werden soll. Die im Ausgabeverzeichnis entstandene raw-Datei ist das zu importierende VM-Image.

Anmerkung: Bei anderen Virtualisierungs-Lösungen, wie z.B. VMware oder VirtualBox, besteht i.d.R. ebenfalls die Möglichkeit einer Konvertierung der Images. Bei den genannten Beispielen ist diese Funktionalität entsprechend im qemu-Toolkit integriert.

Import der VM-Images in OpenNebula

Die schnellste Variante für den Import der VM-Images ist die Verwendung der Kommandozeile. Dazu müssen die raw-Dateien für den KVM-Node zugänglich sein, auf dem OpenNebula installiert ist. Ist diese Bedingung erfüllt, wird sich optimalerweise wieder per ssh mit diesem Node verbunden. Dort ist mit einem dazu berechtigtem User folgender Befehl auszuführen:

oneimage create -d DSID --name NAME --path RAWDATEI --type OS [--persistent]

Dabei ist DSID die ID des Datastores, in der das Image gespeichert werden soll, NAME der Anzeigename des Images und RAWDATEI der Pfad der zuvor entstandenen raw-Datei (mit .raw-Endung). Als Zusatz gibt es das optionale Flag "--persistent", mit dem das Image als persistent angelegt werden kann.

Starten vom neuen Image

Ist das neue Image zur Verwendung freigegeben (Status READY), kann nun aus einem VM-Template eine Instanz mit diesem Image als Startdisk initiiert werden. Nach dem Starten dieser VM-Instanz sind i.d.R. keine weiteren Eingriffe in Konfigurationen notwendig.

Resume

Das obige Szenario erwies sich in unserem Unternehmen als äußerst erfolgreich. Innerhalb weniger Stunden wurden alle relevanten Proxmox VE-VMs in das OpenNebula-Cluster migriert. Durch die zudem stärkere Hardware ergaben sich signifikante Leistungssteigerungen, besonders im Seitenaufbau von Webservern. 

 


Opennebula LVM Datastore – The missing link



Recently we struggled somehow on our first Opennebula Cluster with LVM Datastores.

In the past we‘re using ceph as Storage where the integration with Opennebula is well documented and all in all straight forward.

For an new private Cloud of one of our customers descision was taken to choose HP MSA 1040 with SAS-Controller due to limited budget and as massive scaling is not expected in the near future.

 

So we followed the Opennebula documention but we expirence some aweful lacks of hints how to bring all together.

 

So here what we‘ve done to get the setup running:

 

As mentioned in the docs you don‘t need to have a cLVM (Clustered Logical Volume Manager) in Place. LVS metadata is spread by Opennebula, but you have to be careful regarding some conventions.

 

Create or change Datastores

Take config from original docs

> cat system.conf

NAME = lvm_system

TM_MAD = fs_lvm

TYPE = SYSTEM_DS >

onedatastore create system.conf

ID: 103 cat image.conf

NAME = production

DS_MAD = fs

TM_MAD = fs_lvm

DISK_TYPE = "BLOCK"

TYPE = IMAGE_DS

SAFE_DIRS="/var/tmp /tmp"

> onedatastore create image.conf

ID: 107


Install LVM2 on all nodes

As we‘re running Ubuntu server 16.04LTS

 

sudo apt install lvm2

 

Stop and disable lvm metadata caching daemon lvmetad

 

sudo systemctl stop lvmetad.service

sudo systemctl disable lvmetad.service

 

Change /etc/lvm/lvm.conf on all nodes

 

use_lvmetad = 0

 

Add user oneadmin to group „disk“

 

sudo moduser -a -G disk oneadmin

 

Setup LVM pv, vg

 

If you like to run System and Image Datastore on LVM create two Physical Volumes. As we have only one RAID we first created to partitions with approbriate sizes with fdisk.

 

sudo pvcreate /dev/sdb1

sudo pvcreate /dev/sdb2

 

Now the tricky part:

For the system datastore you must create a volume group with the naming convention vg-one-<DatastoreId>. In our case we have 103 as System datastore id

 

sudo vgcreate /dev/sdb1 vg-one-103

 

Create volume group and logical volume for Images

 

sudo vgcreate /dev/sdb2 vg-one-107

sudo lvcreate vg-one-107 images

 

About the next steps to bring up Image datastore we come back later.

 

Ensure with vgscan that all hosts in cluster

vgscan

Reading all physical volumes. This may take a while...

Found volume group "vg-one-103" using metadata type lvm2

Found volume group "vg-one-107" using metadata type lvm2

 

 

Right now you should have the system datastore in place and ready to run.

 

Image Datastore

In contrast to system datastore you need to have a file system on image datastore and have something like NFS or GlusterFS in place to make the images accessable for the nodes.

Create filesystem on LV „images“

sudo mkfs.ext4 /dev/vg-one-107/images


Mount the volume e.g.

mount /dev/vg-one-107/image /mnt/images

Add to fstab to make mapping persistant

 

Install nfs-server on frontend


sudo apt install nfs-kernel-server


Export the image directory

 

Add the directory and nodes to /etc/exports

/mnt/images node02(rw,sync,no_subtree_check,no_root_squash) node03(rw,sync,no_subtree_check,no_root_squash)

! ensure too add the no_root_squash option !


Create symblic link to datastore

ln -s /mnt/images /var/lib/one/datastore/107

and change owner to oneadmin

chown -R oneadmin:oneadmin /var/lib/one/datastore/107



NFS Settings on cluster nodes

Install nfs

sudo apt install nfs-common

create mounting point

mkdir /mnt/images

add nfs export to /etc/fstab

192.168.123.123:/mnt/images /mnt/images nfs rw,soft,intr,rsize=32768,wsize=32768 0 0

mount -a

Create symbolic link to datastore

ln -s /mnt/images /var/lib/one/datastore/107

change owner to oneadmin

That‘s all!

You have to keep in mind that you have to change your exports at nfs server in case you add a new node to your cluster.