Το προφίλ μας στο Google Plus
0

Κλωνοποίηση QEMU/KVM VMs, σωστά και γρήγορα

Σε προηγούμενο άρθρο δείξαμε πώς δημιουργούμε QEMU/KVM VMs, ξεκινώντας από το μηδέν κι εργαζόμενοι αποκλειστικά από τη γραμμή εντολών. Έφτασε η ώρα να δούμε και μια γρήγορη μέθοδο κλωνοποίησης εικονικών μηχανών, χωρίς φυσικά να αφήσουμε το αγαπημένο (και βολικό) τερματικό.

Στην παρουσίασή μας για τη γρήγορη κι αυτοματοποιημένη ανάπτυξη μηχανών QEMU/KVM, μεταξύ άλλων συζητήσαμε και για την προετοιμασία template VMs. Υποθέτουμε πως έχετε διαβάσει το σχετικό άρθρο, καθώς κι ότι είσαστε εξοικειωμένοι με τις σχετικές έννοιες κι εργαλεία. Το όλο setup για τη συνέχεια έχει ως εξής:

  • εργαζόμαστε σε έναν physical host με openSUSE Leap (θα μπορούσε να τρέχει άλλη διανομή Linux)
  • η απαραίτητη υποδομή λογισμικού για τη δημιουργία και διαχείριση QEMU/KVM VMs, είναι παρούσα
  • υπάρχει το template VM ονόματι leapzero, με το καινούργιο openSUSE Leap 42.3 εγκατεστημένο (θα μπορούσε να έχει άλλο guest OS)
  • ο εικονικός δίσκος του leapzero είναι ένα QCOW2 image, το leapzero.qcow2, εντός του pool ονόματι delta (κατάλογος /mnt/keflavik/pools/delta).

Ενημέρωση template VM

Από μια κονσόλα τερματικού ελέγχουμε αν το leapzero είναι ενεργό, π.χ., πληκτρολογώντας virsh list. Αν δεν είναι, το ενεργοποιούμε δίνοντας virsh start leapzero. Συνδεόμαστε μέσω SSH στο VM (π.χ., ssh userson@leapzero.colder.is) και φρεσκάρουμε τις πληροφορίες για τα repositories της διανομής (sudo zypper ref). Κοιτάμε για τυχόντα updates (zypper lu) και, αν υπάρχουν, εφαρμόζουμε τα αντίστοιχα patches (sudo zypper -n patch). Ίσως αναβαθμιστεί ο πυρήνας, οπότε σε μια τέτοια περίπτωση επανεκκινούμε το VM (sudo reboot). Όταν η όλη διαδικασία της αναβάθμισης ολοκληρωθεί, έχουμε ένα πλήρως ενημερωμένο template VM. Για τη συνέχεια δεν το θέλουμε ενεργοποιημένο, οπότε αν είμαστε συνδεδεμένοι αποσυνδεόμαστε και κατόπιν κλείνουμε τη μηχανή (virsh shutdown leapzero).

Κλωνοποίηση δίσκου

Θα κλωνοποιήσουμε πρώτα το δίσκο του template VM, ώστε να είμαστε βέβαιοι ότι ο δίσκος του νέου VM θα είναι επίσης sparse file:

userson at siglufjörður ~> virsh vol-clone \
> --pool delta leapzero.qcow2 aclone.qcow2

Στο εργαλείο virsh δώσαμε την εντολή vol-clone και σ’ αυτή περάσαμε:

  • το όνομα του pool στο οποίο βρίσκεται το αρχικό volume (delta, μέσα στο ίδιο pool θα δημιουργηθεί και το νέο volume)
  • το όνομα του αρχικού volume (leapzero.qcow2)
  • το όνομα του volume-κλώνου (aclone.qcow2)

Η λειτουργία της κλωνοποίησης θα διαρκέσει κάποια δευτερόλεπτα. Ο συνολικός χρόνος εξαρτάται από το είδος και την ταχύτητα του φυσικού δίσκου επί του οποίου βρίσκεται το pool, καθώς κι από το μέγεθος του πρωτότυπου QCOW2 image. Όταν η κλωνοποίηση ολοκληρωθεί θα πάρουμε ένα μήνυμα σαν αυτό: Vol aclone.qcow2 cloned from leapzero.qcow2. Όλα καλά, πάμε τώρα να δημιουργήσουμε ένα νέο VM με βάση το leapzero.

Κλωνοποίηση μηχανής

Αρκεί να πληκτρολογήσουμε…

userson at siglufjörður ~> virt-clone -o leapzero -n aclone \
> --preserve-data -f /mnt/keflavik/pools/delta/aclone.qcow2

…και σχεδόν ακαριαία θα πάρουμε το μήνυμα Clone 'aclone' created successfully. Παρατηρήστε ότι:

  • αντί για το εργαλείο virsh αυτή τη φορά καταφύγαμε στο virt-clone
  • η παράμετρος -o δέχεται το όνομα της πρωτότυπης μηχανής (leapzero)
  • η παράμετρος -n δέχεται το όνομα της μηχανής-κλώνου (aclone, θα μπορούσαμε να είχαμε δώσει οτιδήποτε άλλο)
  • το --preserve-data σημαίνει ότι δεν θέλουμε να κλωνοποιηθεί κάποιο volume, αλλά μόνο το XML του αρχικού VM
  • η παράμετρος -f ακολουθείται από το πλήρες path προς το QCOW2 image που θα αποτελέσει το δίσκο της κλωνοποιημένης μηχανής

Κλώνος μεν, μοναδικός δε

Μόλις δημιουργήσαμε τον πρώτο μας κλώνο, με βάση το template VM που έχουμε στη διάθεσή μας. Πριν κάνουμε οτιδήποτε άλλο, ας δούμε μερικές πληροφορίες που αφορούν στο template VM:

userson at siglufjörður ~> virsh dominfo leapzero
Id:             -
Name:           leapzero
UUID:           3665fef8-c505-4700-b3f1-8a062a3f7d34
OS Type:        hvm
State:          shut off
CPU(s):         2
Max memory:     2097152 KiB
Used memory:    2097152 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: apparmor
Security DOI:   0

Στην τρίτη γραμμή των αποτελεσμάτων, βλέπουμε την τιμή του UUID (Universally Unique IDentifier) για το template VM. Το UUID είναι μοναδικό για κάθε VM — ή τουλάχιστον θα πρέπει να είναι μοναδικό. Πριν λίγο κλωνοποιήσαμε το template VM, οπότε τώρα είναι λογικό ν’ αναρωτηθούμε για το UUID του κλώνου. Από τη στιγμή που μιλάμε για κλωνοποίηση, είναι λογικό να υποθέσουμε ότι τα UUIDs των leapzero και aclone είναι ίδια. Εκτός βέβαια κι αν το virt-clone είναι αρκετά έξυπνο και για τους κλώνους φροντίζει και παράγει νέα UUIDs. Είναι όμως τόσο έξυπνο; Δεν χρειάζεται ν’ αναρωτιόμαστε:

userson at siglufjörður ~> virsh dominfo aclone
Id:             -
Name:           aclone
UUID:           fee9aa57-2e2d-489b-ba1e-e317933823d0
OS Type:        hvm
State:          shut off
CPU(s):         2
Max memory:     2097152 KiB
Used memory:    2097152 KiB
Persistent:     yes
Autostart:      disable
Managed save:   no
Security model: apparmor
Security DOI:   0

Πολύ ωραία, είναι τόσο έξυπνο. Για την ακρίβεια είναι εξυπνότερο, αφού εκτός από τα UUIDs φροντίζει να παράγει και MAC addresses για τις κάρτες δικτύου. Δείτε, π.χ., το MAC address που έχει η εικονική κάρτα Ethernet του leapzero

userson at siglufjörður ~> virsh dumpxml leapzero | grep "mac address" | \
> awk -F "<mac address='" '{ print $2 }' | awk -F "'/>" '{ print $1 }'
52:54:00:17:30:60

…κι αμέσως μετά το MAC address που έχει η αντίστοιχη κάρτα του aclone:

userson at siglufjörður ~> virsh dumpxml aclone | grep "mac address" | \
> awk -F "<mac address='" '{ print $2 }' | awk -F "'/>" '{ print $1 }'
52:54:00:c5:25:0a

Διαπιστώνουμε, λοιπόν, ότι ο κλώνος δεν είναι ακριβώς ίδιος με το template VM, αλλά εκεί που πρέπει να διαφοροποιείται πράγματι διαφοροποιείται.

Ενεργοποίηση κλώνου κι ένα θεματάκι δικτύωσης

Στο σημείο αυτό μπορούμε να ξεκινήσουμε τον κλώνο, π.χ., δίνοντας virsh start aclone. Το template VM περιλαμβάνει το δημόσιο κλειδί του χρήστη μας στον physical host, επομένως το ίδιο ισχύει και για τον κλώνο. Έτσι, μετά από λίγα δευτερόλεπτα θα είμαστε σε θέση για SSH login στο λογαριασμό του userson στο aclone, χωρίς την πληκτρολόγηση του αντίστοιχου password (το οποίο, παρεμπιπτόντως, σκόπιμα είχαμε φροντίσει ώστε να είναι το πολύ απλό topsecret).

Θα θυμόσαστε εξάλλου ότι το AutoYaST profile που είχαμε χρησιμοποιήσει για την αυτόματη εγκατάσταση του openSUSE Leap 42.3 στο leapzero, θέτει το ίδιο ακριβώς όνομα ως hostname της μηχανής. Η ρύθμιση αυτή θα ισχύει και για τον κλώνο μας. Καταλαβαίνετε, λοιπόν, ότι εδώ έχουμε μια κάπως περίεργη κατάσταση, αφού ένα VM που ονομάζεται aclone λέει ότι θέλει ως hostname το leapzero. Ακόμα χειρότερα, αν ενεργοποιήσουμε και το template VM, τότε θα έχουμε δύο μηχανές που θα λένε ότι θέλουν το ίδιο hostname. Το τι θα συμβεί στην πράξη εξαρτάται από τον (φυσικό ή εικονικό) DHCP server, ο οποίος υπομονετικά κι επιμελώς φροντίζει για τις παραμέτρους δικτύωσης των πελατών του. Κάποιοι DHCP servers εξ ορισμού δίνουν ένα τυχαίο hostname στους πελάτες τους — εκτός κι αν ρυθμιστούν διαφορετικά. Στην περίπτωσή σας το πιθανότερο είναι ότι έχετε πλήρη πρόσβαση στον DHCP server που εξυπηρετεί τις φυσικές ή/και τις εικονικές σας μηχανές. Γενικά, ζητήματα που αφορούν στη διευθυνσιοδότηση (IPs) κι ονοματολογία (hostnames, domain names) των δικτυωμένων συσκευών, είναι πολύ βολικό να διευθετούνται κεντρικά, από τον ίδιο τον DHCP server. Όσο για τους πελάτες, αυτοί δεν ξεχωρίζουν με βάση τα hostnames που λένε ότι έχουν, αλλά με βάση τα (μοναδικά) MAC addresses των network adapters μέσω των οποίων μιλούν με τον αξιότιμο κύριο DHCP server. Ο δικός μας DHCP server, για παράδειγμα, είναι ο dnsmasq. Στο configuration file έχουμε δύο entries, ώστε τα leapzero (MAC address 52:54:00:17:30:60) και aclone (MAC address 52:54:00:c5:25:0a) να παίρνουν πάντα τα hostnames που θέλουμε:

dhcp-host=52:54:00:17:30:60,leapzero
dhcp-host=52:54:00:c5:25:0a,aclone

Προτείνουμε μια παρόμοια διευθέτηση και για τον δικό σας DHCP server. Προαιρετικά, συνδεθείτε στον κλώνο και με τη βοήθεια του YaST αλλάξτε το hostname που η μηχανή γνωστοποιεί στο δίκτυο. Φυσικά, μια τέτοια χειροκίνητη επέμβαση γίνεται γρήγορα άβολη όταν μιλάμε για πολλές μηχανές. Σε τέτοιες περιπτώσεις είναι προτιμότερο να έχουμε καταστρώσει ένα script που δημιουργεί λίστες με ζεύγη της μορφής <MAC_address, hostname> όπου το hostname θα ‘ναι ίδιο με το όνομα της εκάστοτε μηχανής. Αν θέλουμε να πάμε τον αυτοματισμό λίγο παραπέρα, το script θα ενημερώνει αυτόματα τον DHCP server. Είναι φυσικά πολλά αυτά που μπορούμε να κάνουμε, κι όπως υποψιαζόσαστε μόλις δώσαμε αθώα spoilers επόμενων άρθρων.

Ιδού το template VM (leapzero) κι ένας κλώνος του (aclone). Ανεξαρτήτως του hostname που λένε ότι έχουν οι μηχανές, ο DHCP server του τοπικού δικτύου φροντίζει να τους δίνει hostnames βάσει του MAC address καθενός. Οι κανόνες ονοματολογίας έχουν οριστεί από τον διαχειριστή του DHCP server.

Προσθήκη νέου δίσκου στον κλώνο

Ας υποθέσουμε τώρα ότι θέλουμε να χρησιμοποιήσουμε τον κλώνο μας ως host για το Nextcloud. Το αντίστοιχο VM θα χρειαστεί ένα δεύτερο δίσκο, η χωρητικότητα του οποίου αρκεί να είναι στα 512GiB. Δημιουργούμε λοιπόν ένα νέο QCOW2 image, μέσα στο storage pool ονόματι delta:

userson at siglufjörður ~> virsh vol-create-as delta \
> --name aclone_data.qcow2 --capacity 512G --format qcow2

Η δημιουργία του aclone_data.qcow2 ολοκληρώνεται ακαριαία (μην ξεχνάτε ότι πρόκειται για sparse file). Επαληθεύουμε πως όλα είναι όπως πρέπει:

userson at siglufjörður ~> virsh vol-list delta
Name                 Path                                    
--------------------------------------------------------------------
aclone.qcow2         /mnt/keflavik/pools/delta/aclone.qcow2
aclone_data.qcow2    /mnt/keflavik/pools/delta/aclone_data.qcow2
leapzero.qcow2       /mnt/keflavik/pools/delta/leapzero.qcow2

Πολύ ωραία. Ας συνδέσουμε τώρα τον καινούργιο δίσκο στη μηχανή:

userson at siglufjörður ~> virsh attach-disk aclone \
> /mnt/keflavik/pools/delta/aclone_data.qcow2 vdb \
> --driver qemu --subdriver qcow2 --targetbus virtio --persistent

Παρατηρήστε ότι δεν χρειάζεται να κλείσουμε την εικονική μηχανή, προκειμένου να της προσθέσουμε έναν δίσκο. Αφού λοιπόν συνδεθούμε μέσω SSH στον κλώνο και πληκτρολογήσουμε sudo fdisk -l, θα διαπιστώσουμε ότι έχει δύο δίσκους: τον /dev/vda (αυτός φιλοξενεί το λειτουργικό), καθώς και τον /dev/vdb (αυτός είναι ο νέος δίσκος που προσθέσαμε μόλις). Μπορούμε τώρα να δημιουργήσουμε μία ή περισσότερες κατατμήσεις επί του vdb, να τις διαμορφώσουμε, να τις προσαρτήσουμε και, γενικά, να χρησιμοποιούμε το δίσκο όπως επιθυμούμε.

Να κι ένας νέος δίσκος για τον κλώνο μας, τον οποίο μάλιστα προσθέσαμε ενώ η μηχανή ήταν ενεργή.

Μεταβολή άλλων χαρακτηριστικών του κλώνου

Αναλόγως της εφαρμογής, η ελαστικότητα των εικονικών μηχανών αποδεικνύεται πολύτιμη. Δείτε για παράδειγμα πόσο εύκολο είναι να διπλασιάσουμε τη μνήμη RAM του κλώνου. Με την προϋπόθεση ότι το aclone είναι ανενεργό (powered off), πληκτρολογούμε:

userson at siglufjörður ~> virsh setmaxmem aclone 4194304 --config
userson at siglufjörður ~> virsh setmem aclone 4194304 --config

Και μιας και διπλασιάσαμε τη μνήμη, ας διπλασιάσουμε και τον αριθμό των εικονικών επεξεργαστών (από 2 σε 4):

userson at siglufjörður ~> virsh setvcpus aclone 4 --config --maximum
userson at siglufjörður ~> virsh setvcpus aclone 4 --config

Ξεκινήστε το aclone, συνδεθείτε μέσω SSH και τρέξτε το top. Παρατηρήστε ότι η μνήμη της μηχανής είναι στα 4GiB (το μέγεθός της εκφράζεται σε KiB, επομένως το σχετικό νούμερο που θα δείτε πάνω αριστερά είναι το 4045656). Εγκαταλείψτε το top (απλά πιέστε το πλήκτρο [Q]) και πληκτρολογήστε cat /proc/cpuinfo. Θα διαπιστώσετε ότι η μηχανή έχε τέσσερις επεξεργαστές (processor 0 έως και processor 3). Τέλος, επαναλάβετε μετά από εμάς: “το virtualization είναι ευλογία”.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων