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

To KVM για αληθινούς administrators

Στο τεύχος 049 είδαμε πώς μετατρέπουμε ένα ταπεινό PC σε πανίσχυρο virtualization host, με τη βοήθεια του openSUSE και του KVM. Το GNOME desktop που επιλέξαμε για το openSUSE αφενός διευκόλυνε τη γνωριμία μας με το KVM, αφετέρου τον συγκεκριμένο host μερικές φορές θέλουμε να τον χρησιμοποιούμε κι ως απλό σύστημα desktop. Στο παρόν άρθρο δείχνουμε πώς δημιουργούμε και διαχειριζόμαστε KVM VMs αποκλειστικά από τη γραμμή εντολών.

Ειδικά όσοι φιλοδοξούν ν’ ασχοληθούν σοβαρά με τη διαχείριση σύγχρονων συστημάτων και δικτύων, πιστεύουμε ότι αξίζει να δώσουν προσοχή και φυσικά να πειραματιστούν στην πράξη. Πριν ξεκινήσουμε, ας σημειώσουμε ότι αν δεν έχετε ακόμη διαβάσει τα σχετικά άρθρα στο τεύχος 049, καλό θα ήταν να το πράξετε τώρα (βλ. εδώ κι εδώ).

Για τη συνέχεια δουλεύουμε είτε τοπικά, από μια κονσόλα του virtualization host, είτε απομακρυσμένα, μέσω SSH. Το username του δικού μας χρήστη είναι cvar, ενώ το hostname του μηχανήματος είναι thehost. Οι εντολές που δίνουμε απαιτούν δικαιώματα διαχειριστή συστήματος, γι’ αυτό και κάνουμε χρήση του sudo.

Βασική διαχείριση υπαρχόντων KVM VMs
Θα καταφύγουμε στο εργαλείο virsh. Τις υπάρχουσες εικονικές μηχανές, ασχέτως αν είναι ενεργές ή όχι, τις βλέπουμε πληκτρολογώντας

<br />
cvar@thehost:~&gt; sudo virsh list --all<br />
 Id    Name                           State<br />
----------------------------------------------------<br />
 1     Plex                           running<br />
 2     DbxNode                        running<br />
 3     OpenBSD                        running<br />
 -     FreeBSD                        shut off<br />
cvar@thehost:~&gt;<br />

Ας εξετάσουμε τις στήλες του πίνακα. Στην “Id” βλέπουμε έναν μοναδικό ακέραιο αριθμό, ο οποίος αντιστοιχίζεται σε κάθε ενεργή μηχανή. Στη στήλη “Name” υπάρχουν τα ονόματα των μηχανών, όπως ορίστηκαν κατά τη δημιουργία τους. Στη δε στήλη “State” αναφέρεται η κατάσταση κάθε μηχανής. Στο παράδειγμά μας οι μηχανές Plex, DbxNode και OpenBSD είναι ενεργές (running), ενώ η FreeBSD είναι ανενεργή (shut off). Στο virsh δώσαμε την εντολή list και την παράμετρο –all. Παραλείποντας την τελευταία, παίρνουμε μια λίστα με τις ενεργές μηχανές και μόνον αυτές. Προκειμένου να ξεκινήσουμε μια ανενεργή μηχανή, αρκεί να γράψουμε κάτι σαν

<br />
cvar@thehost:~&gt; sudo virsh start FreeBSD<br />
Domain FreeBSD started<br />
cvar@thehost:~&gt;<br />

Μετά την εντολή start απλά παραθέσαμε το όνομα της εικονικής μηχανής που αποφασίσαμε να ενεργοποιήσουμε. Παρατηρήστε το μήνυμα που μας επεστράφη: τα virtual machines ονομάζονται και domains — και η συγκεκριμένη ορολογία προέρχεται από τον κόσμο του Xen. Προκειμένου να κλείσουμε ομαλά ένα VM, όπου με το “ομαλά” εννοούμε όπως θα κλείναμε έναν φυσικό υπολογιστή, χωρίς να τον βγάλουμε από την πρίζα, πληκτρολογούμε κάτι σαν

<br />
cvar@thehost:~&gt; sudo virsh shutdown FreeBSD<br />
Domain FreeBSD is being shutdown<br />
cvar@thehost:~&gt;<br />

Στη θέση του ονόματος (FreeBSD) θα μπορούσαμε να είχαμε βάλει το Id. Όπως είδαμε πριν από λίγο, τα Ids και τα ονόματα των μηχανών παρατίθενται στην έξοδο της εντολής “virsh list”. Για την επανεκκίνηση (reboot) μιας μηχανής, δίνουμε

<br />
cvar@thehost:~&gt; sudo virsh reboot OpenBSD<br />
Domain OpenBSD is being rebooted<br />
cvar@thehost:~&gt;<br />

Είναι πιθανό κάποια μηχανή να μην ανταποκρίνεται σε εντολές για reboot ή shutdown. Συνήθεις λόγοι είναι η ελλιπής –ή η καθόλου– υποστήριξη του προτύπου ACPI, όπως επίσης και οι ρυθμίσεις του guest OS. Κατά περιπτώσεις, όπως, π.χ., μέσα από κάποιο script, θα θέλουμε να κλείνουμε ακόμη κι αυτές τις μηχανές, οπότε η εντολή που θα περνάμε στο virsh θα είναι η destroy:

<br />
cvar@thehost:~&gt; sudo virsh destroy OpenBSD<br />
Domain OpenBSD destroyed<br />
cvar@thehost:~&gt;<br />

Όσα συζητήσαμε έως τώρα για το πώς ξεκινάμε, σταματάμε κι επανεκκινούμε εικονικές μηχανές, αφορούν στο λεγόμενο lifecycle management των VMs. Σίγουρα δεν είναι από τις πιο δύσκολες εργασίες, όμως σε διάφορα περιβάλλοντα είναι ιδιαίτερα σημαντικές κι ενίοτε εκτελούνται αυτοματοποιημένα, από κατάλληλα scripts. Παρεμπιπτόντως, ειδικά για το αυτόματο boot ενός VM κατά την εκκίνηση του host OS αρκεί να πληκτρολογήσουμε (μία φορά) το ακόλουθο:

<br />
cvar@thehost:~&gt; sudo virsh autostart FreeBSD<br />
Domain FreeBSD marked as autostarted<br />
cvar@thehost:~&gt;<br />

Αργότερα, αν για κάποιο λόγο αποφασίσουμε ότι ένα VM δεν πρέπει να bootάρει αυτόματα κατά την εκκίνηση του host OS, αρκεί να δώσουμε κάτι σαν

<br />
cvar@thehost:~&gt; sudo virsh autostart --disable FreeBSD<br />
Domain FreeBSD unmarked as autostarted<br />
cvar@thehost:~&gt;<br />

Πρόσβαση σε κονσόλα KVM VM, απομακρυσμένα
Ο προφανής τρόπος είναι να καταφύγουμε σε κάποια μέθοδο που υποστηρίζει το guest OS του VM που μας ενδιαφέρει. Αν, π.χ., έχουμε ένα Unix-like guest OS, τότε πιθανώς να συνδεθούμε σ’ αυτό μέσω SSH ή VNC. Αν πάλι μιλάμε για Windows guest, τότε μια δυνατότητα σύνδεσης παρέχεται από το Remote Desktop Protocol. Τι γίνεται όμως αν το guest OS δεν έχει καν εγκατασταθεί ή έχει εγκατασταθεί αλλά δεν παρέχει κάποια μέθοδο απομακρυσμένης σύνδεσης; Σε μια τέτοια περίπτωση το ιδανικό είναι να έχουμε μπροστά μας την κονσόλα του VM, ασχέτως αν αυτή είναι text ή graphics-based, όπως έχουμε μπροστά μας την οθόνη ενός φυσικού υπολογιστή. Αυτό θα το πετυχαίναμε αν, π.χ., τρέχαμε τον Virtual Machine Manager στο απομακρυσμένο host computer, δηλαδή στον virtualization host, αλλά το λεγόμενο display του προγράμματος γινόταν στην οθόνη του υπολογιστή από τον οποίο τώρα εργαζόμαστε. Θα υποψιάζεστε, βεβαίως, πως ό,τι περιγράψαμε είναι πέρα για πέρα εφικτό. Και πράγματι είναι, αρκεί να ισχύουν οι τρεις ακόλουθες προϋποθέσεις:

Π1. Στον virtualization host τρέχει SSH server, ο οποίος επιτρέπει το λεγόμενο X11 forwarding.

Π2. Ο απλός χρήστης του virtualization host, στο λογαριασμό του οποίου κάνουμε SSH login, ανήκει στο group ονόματι libvirt.

Π3. Στον υπολογιστή από τον οποίο εργαζόμαστε υπάρχει πρόγραμμα για συνδέσεις SSH, αλλά και κάποιος X server.

Aς δούμε τις Π1, Π2 και Π3 αναλυτικά.

Π1. Ο virtualization host με το openSUSE τρέχει ήδη SSH server, ο οποίος δέχεται συνδέσεις από οποιονδήποτε client. Για λόγους ασφαλείας δεν επιτρέπει SSH logins στο λογαριασμό του χρήστη root. Επίσης, για τους απλούς χρήστες επιτρέπει μόνο passwordless logins, με βάση τα αντίστοιχα δημόσια κλειδιά SSH. Τέλος, ο SSH server του openSUSE μας εξ ορισμού επιτρέπει το X11 forwarding — όπως άλλωστε συμβαίνει και με πολλές άλλες διανομές Linux.

Π2. Ο απλός μας χρήστης θα πρέπει να ανήκει στο group ονόματι libvirt, διαφορετικά δεν θα μπορεί να διαχειρίζεται εικονικές μηχανές. Από τη στιγμή βέβαια που κάνουμε SSH login στο λογαριασμό του, θα μπορούσε κάποιος να προτείνει κι ένα sudo su ώστε να περάσουμε στο λογαριασμό του root. Το θέμα είναι ότι κατ’ αυτόν τον τρόπο περιπλέκονται τα πράγματα με την ανακατεύθυνση του display των εφαρμογών γραφικών, οπότε καλύτερα να μην ακολουθήσουμε τη συγκεκριμένη οδό. Τώρα, ένας τρόπος για να βάλουμε τον απλό μας χρήστη στο group libvirt, είναι από τη γραμμή εντολών και με τη βοήθεια του εργαλείου usermod:

<br />
cvar@thehost:~&gt; sudo usermod -a -G libvirt cvar<br />

Η προσθήκη του cvar στο group libvirt δεν έχει ληφθεί ακόμη υπόψη, όπως φανερώνει και η έξοδος του εργαλείου groups:

<br />
cvar@thehost:~&gt; groups<br />
users<br />

Στο σημείο αυτό μπορούμε να κάνουμε ένα logout και ξανά login και θα δούμε ότι ο χρήστης μας όντως ανήκει στο group libvirt. Εναλλακτικά, καταφεύγουμε στο newgrp:

<br />
cvar@thehost:~&gt; newgrp libvirt<br />
cvar@thehost:~&gt; groups<br />
libvirt users<br />
cvar@thehost:~&gt;<br />

Όλα καλά.

Με το πολυεργαλείο διαχείρισης συστήματος YaST του openSUSE μπορούμε να κάνουμε σχεδόν τα πάντα, ακόμη και τις ταπεινές εργασίες όπως είναι η προσθήκη ενός χρήστη σ' ένα νέο group. Φανταζόμαστε, πάντως, πως θα συμφωνήσετε κι εσείς ότι ορισμένες τέτοιες 'ταπεινές εργασίες' γίνονται πολύ πιο γρήγορα από τη γραμμή εντολών.

Με το πολυεργαλείο διαχείρισης συστήματος YaST του openSUSE μπορούμε να κάνουμε σχεδόν τα πάντα, ακόμη και τις ταπεινές εργασίες όπως είναι η προσθήκη ενός χρήστη σ’ ένα νέο group. Φανταζόμαστε, πάντως, πως θα συμφωνήσετε κι εσείς ότι ορισμένες τέτοιες “ταπεινές εργασίες” γίνονται πολύ πιο γρήγορα από τη γραμμή εντολών.

Π3. Αν δουλεύουμε από σύστημα Linux ή BSD, στο οποίο είναι εγκατεστημένος X server, αρκεί να συνδεθούμε στον virtualization host με το ssh δίνοντάς του την παράμετρο -Χ (κεφαλαίο). Πληκτρολογώντας στο τερματικό το όνομα μιας απομακρυσμένης εφαρμογής γραφικών, το display της θα ανακατευθύνεται στην οθόνη του υπολογιστή μας. Αν πάλι δουλεύουμε από OS X, κατά πάσα πιθανότητα θα χρειαστεί να εγκαταστήσουμε πρώτα το πακέτο XQuartz. Από εκεί και μετά, όποτε θέλουμε να τρέξουμε μια απομακρυσμένη εφαρμογή γραφικών θα ανοίγουμε ένα Terminal, θα συνδεόμαστε στο openSUSE με το ssh και την παράμετρο -X, και φυσικά θα πληκτρολογούμε το όνομα της εφαρμογής. Σημειώστε ότι δεν χρειάζεται να ξεκινάμε μόνοι μας το XQuartz, αφού κάθε φορά που το OS X το χρειάζεται το ενεργοποιεί αυτόματα. Τελευταία αφήσαμε την περίπτωση των Windows. Εξαιρετικά δημοφιλής SSH client για τα Windows, με δυνατότητες για X11 forwarding, είναι το PuTTY. Πρέπει βέβαια να εγκαταστήσουμε και κάποιον X server, όπως, π.χ., είναι το Xming. Μια εναλλακτική πρόταση είναι το MobaXterm, το οποίο έχει *και SSH client και X server.

Σε κάθε περίπτωση, αφού συνδεθούμε μέσω SSH (και την παράμετρο -X ή το ισοδύναμό της) στο λογαριασμό του χρήστη μας στον virtualization host, πληκτρολογούμε απλά “virt-manager” (χωρίς τα εισαγωγικά) και πατάμε [Enter]. Στην οθόνη μας θα δούμε το παράθυρο του Virtual Machine Manager και με διπλό κλικ στη γραμμή του επιθυμητού VM θα ανοίξει η κονσόλα του.

Από το laptop μας με OS X El Capitan ανοίγουμε ένα τερματικό, συνδεόμαστε με το ssh στον virtualization host (προσέξτε την παράμετρο -X) και πληκτρολογούμε 'virt-manager', χωρίς τα εισαγωγικά (1). Το OS X σηκώνει το XQuartz και μερικά πικοδευτερόλεπτα αργότερα, τα οποία για ένα συγκεκριμένο επίπεδο ύπαρξης συγγενεύουν με την αιωνιότητα, στην ωραία μας οθόνη βλέπουμε το παράθυρο του Virtual Machine Manager, ο οποίος φυσικά τρέχει στο PC με το openSUSE. Με κλικ πάνω στο επιθυμητό KVM VM (2), στην οθόνη έχουμε και την κονσόλα του (3). Η ρουτίνα που μόλις περιγράψαμε είναι ιδιαίτερα βολική, π.χ., όταν σε κάποιο VM δεν έχει ακόμα εγκατασταθεί το guest OS και ταυτόχρονα αδυνατούμε ή έστω δεν μας βολεύει να πάμε να καθήσουμε μπροστά από τον physical host, ώστε να την προχωρήσουμε.

Από το laptop μας με OS X El Capitan ανοίγουμε ένα τερματικό, συνδεόμαστε με το ssh στον virtualization host (προσέξτε την παράμετρο -X) και πληκτρολογούμε “virt-manager”, χωρίς τα εισαγωγικά (1). Το OS X σηκώνει το XQuartz και μερικά πικοδευτερόλεπτα αργότερα, τα οποία για ένα συγκεκριμένο επίπεδο ύπαρξης συγγενεύουν με την αιωνιότητα, στην ωραία μας οθόνη βλέπουμε το παράθυρο του Virtual Machine Manager, ο οποίος φυσικά τρέχει στο PC με το openSUSE. Με κλικ πάνω στο επιθυμητό KVM VM (2), στην οθόνη έχουμε και την κονσόλα του (3). Η ρουτίνα που μόλις περιγράψαμε είναι ιδιαίτερα βολική, π.χ., όταν σε κάποιο VM δεν έχει ακόμα εγκατασταθεί το guest OS και ταυτόχρονα αδυνατούμε ή έστω δεν μας βολεύει να πάμε να καθήσουμε μπροστά από τον physical host, ώστε να την προχωρήσουμε.

Το MobaXterm είναι μια ενδιαφέρουσα πρόταση για τους χρήστες των Windows που αναζητούν SSH client και X server, ώστε να είναι σε θέση να τρέχουν απομακρυσμένες εφαρμογές Unix και να έχουν το display τους τοπικά.

Το MobaXterm είναι μια ενδιαφέρουσα πρόταση για τους χρήστες των Windows που αναζητούν SSH client και X server, ώστε να είναι σε θέση να τρέχουν απομακρυσμένες εφαρμογές Unix και να έχουν το display τους τοπικά.

Δημιουργία KVM VMs
Μέχρι εδώ συζητήσαμε για το lifecycle management των VMs. Δείξαμε επίσης κι έναν ασφαλή τρόπο για την “ανακατεύθυνση” της κονσόλας ενός απομακρυσμένου VM, στην οθόνη του τοπικού μας υπολογιστή. Έχει φτάσει ώρα να ασχοληθούμε και με τη δημιουργία νέων KVM VMs — εννοείται από τη γραμμή εντολών.

Πριν φτιάξουμε ένα VM οφείλουμε ν’ αποφασίσουμε για το είδος του δίσκου του, βεβαίως και να τον δημιουργήσουμε. Μια ενδιαφέρουσα δυνατότητα για το δίσκο είναι ν’ αποτελεί logical volume (LV) ενός προϋπάρχοντος volume group (VG). Γενικά για το Logical Volume Management (LVM) μπορείτε να διαβάσετε εδώ κι εδώ. Η συγκεκριμένη προσέγγιση παρέχει ευελιξία και ταχύτητα. Από την άλλη, ένα τέτοιο setup ίσως είναι περιττά περίπλοκο για απλά σενάρια χρήσης (όπως είναι τα δικά μας). Επιπρόσθετα, τους δίσκους που κατοικούν σε LVs δεν μπορούμε να τους διαχειριζόμαστε εύκολα με κλασικά εργαλεία όπως, π.χ., είναι το scp. Για τη συνέχεια, λοιπόν, ας εστιάσουμε στους εικονικούς δίσκους οι οποίοι ουσιαστικά αποτελούν ένα απλό αρχείο στο filesystem του host OS (εν προκειμένω του openSUSE).

Δύο είναι τα βασικά formats των αρχείων-εικονικών δίσκων: RAW και QCOW2. Το format RAW είναι το πιο απλό και γρήγορο, αλλά και με τις λιγότερες δυνατότητες. Σημειώστε ότι ένα αρχείο RAW επιτρέπεται να είναι sparse, που σημαίνει ότι ο συνολικός του χώρος δεν κατανέμεται κατά τη δημιουργία του αλλά το αρχείο μεγαλώνει δυναμικά, καθώς το guest OS του αντίστοιχου VM αμέριμνα γράφει δεδομένα στο δίσκο. Όπως πιθανώς θα φαντάζεστε, τα RAW files που είναι sparse παρέχουν χαμηλότερη ταχύτητα προσπέλασης σε σύγκριση με τα RAW files που δεν είναι sparse (όλη η έκτασή τους κατανέμεται στο filesystem του host κατά τη δημιουργία τους). Τα αρχεία εξάλλου format QCOW2 μεγαλώνουν κι αυτά δυναμικά, ενώ προσφέρουν και κάποιες έξτρα δυνατότητες όπως, π.χ., το snapshotting. Οι δυνατότητες όμως έχουν και το τίμημά τους, το οποίο δεν είναι άλλο από τη συγκριτικά χαμηλότερη ταχύτητα πρόσβασης. Τελικά, για τις δικές μας απλές ανάγκες προτιμάμε τα sparse RAW files: συνδυάζουν ταχύτητα πρόσβασης και οικονομία χώρου, ενώ και η μεταφορά τους σε άλλο δίσκο ή host computer γίνεται πανεύκολα.

Για τη δημιουργία ενός sparse RAW file, το οποίο σε πολύ λίγο θα αντιστοιχίσουμε στη νέα μας εικονική μηχανή, πληκτρολογούμε κάτι τέτοιο:

<br />
cvar@thehost:~&gt; sudo truncate --size=24576M /var/lib/libvirt/images/husavik.img<br />

Το νέο αρχείο ονομάσαμε husavik.img και το αποθηκεύσαμε κάτω από τον κατάλογo /var/lib/libvirt/images. Δεν μπορούμε να το καθυστερήσουμε άλλο: έφτασε η στιγμή της δημιουργίας της πρώτης μας εικονικής μηχανής από τη γραμμή εντολών, η οποία ως δίσκο της θα έχει το husavik.img. Καταφεύγουμε στο εργαλείο virt-install:

<br />
cvar@thehost:~&gt; sudo virt-install --name CentOS --description &quot;CentOS 7 64bit&quot; \<br />
--memory 1024 --cpu host --vcpus=2 --network bridge=br0,model=virtio \<br />
--disk /var/lib/libvirt/images/husavik.img,bus=virtio \<br />
--cdrom /home/cvar/Downloads/ISOs/CentOS\ 7\ x86_64-Minimal-1511.iso \<br />
--noautoconsole<br />

Οι παράμετροι που περάσαμε στο virt-install δεν είναι λίγες, γι’ αυτό κι ολόκληρη την εντολή τη “σπάσαμε” σε περισσότερες από μία γραμμές. Όποτε θέλαμε ν’ αλλάξουμε γραμή αφήναμε ένα κενό, μετά βάζαμε τον χαρακτήρα “\” (χωρίς τα εισαγωγικά) και πατούσαμε [Enter]. Στην τελευταία γραμμή πατήσαμε μόνο το [Enter] και το BASH έλαβε υπόψη όλα όσα γράψαμε μετά το prompt, σαν να είχαν πληκτρολογηθεί σε μία μόνο γραμμή.

Απομακρυσμένα, κι εργαζόμενοι από το ωραίο τερματικό μας, μόλις δημιουργήσαμε μια νέα εικονική μηχανή. Τα βασικά της υποσυστήματα έχουν ως ακολούθως: 1GB RAM, dual-core CPU με χαρακτηριστικά παρόμοια μ' εκείνα του host computer, δικτύωση τύπου bridged, ώστε το VM να συμμετέχει κανονικά στο τοπικό δίκτυο όπως κάθε άλλος εικονικός ή φυσικός υπολογιστής, σκληρός δίσκος μεγέθους 24GB. Για το δίσκο αλλά και τη δικτύωση χρησιμοποιείται ο VirtIO driver, γεγονός που σημαίνει βελτιωμένες επιδόσεις. Το όνομα της μηχανής είναι CentOS και η εγκατάσταση θα γίνει από το ISO image ονόματι CentOS 7 x86_64-Minimal-1511.iso, μέσα στον κατάλογο /home/cvar/Downloads/ISOs του host. Χάρη εξάλλου στην τελευταία παράμετρο, την --noautoconsole, δεν επιχειρείται το άνοιγμα κάποιας κονσόλας προς το VM. Αυτό θα το κάνουμε εμείς, όποτε κι απ' όπου μας βολεύει. Στο μεταξύ το VM θα έχει ενεργοποιηθεί, θα έχει bootάρει από το εικονικό CDROM και θα περιμένει υπομονετικά ν' ασχοληθούμε με την εγκατάσταση του guest OS.

Απομακρυσμένα, κι εργαζόμενοι από το ωραίο τερματικό μας, μόλις δημιουργήσαμε μια νέα εικονική μηχανή. Τα βασικά της υποσυστήματα έχουν ως ακολούθως: 1GB RAM, dual-core CPU με χαρακτηριστικά παρόμοια μ’ εκείνα του host computer, δικτύωση τύπου bridged, ώστε το VM να συμμετέχει κανονικά στο τοπικό δίκτυο όπως κάθε άλλος εικονικός ή φυσικός υπολογιστής, σκληρός δίσκος μεγέθους 24GB. Για το δίσκο αλλά και τη δικτύωση χρησιμοποιείται ο VirtIO driver, γεγονός που σημαίνει βελτιωμένες επιδόσεις. Το όνομα της μηχανής είναι CentOS και η εγκατάσταση θα γίνει από το ISO image ονόματι CentOS 7 x86_64-Minimal-1511.iso, μέσα στον κατάλογο /home/cvar/Downloads/ISOs του host. Χάρη εξάλλου στην τελευταία παράμετρο, την –noautoconsole, δεν επιχειρείται το άνοιγμα κάποιας κονσόλας προς το VM. Αυτό θα το κάνουμε εμείς, όποτε κι απ’ όπου μας βολεύει. Στο μεταξύ το VM θα έχει ενεργοποιηθεί, θα έχει bootάρει από το εικονικό CDROM και θα περιμένει υπομονετικά ν’ ασχοληθούμε με την εγκατάσταση του guest OS.

Ό,τι πληκτρολογήσαμε δείχνει αρκετά περίπλοκο και κάποιοι θα σκεφτούν ότι όλη αυτή η φασαρία δεν αξίζει τον κόπο. Λέμε ότι οι συγκεκριμένοι “κάποιοι” έχουν λάθος. Αν πιστεύετε ότι το λάθος είναι δικό μας, σας προ(σ)καλούμε σε μια πιο προσεκτική εξέταση των παραμέτρων που δώσαμε στο virt-install.

–name CentOS
Το νέο μας VM το ονομάζουμε CentOS. Είναι γιατί πρόκειται να του εγκαταστήσουμε το CentOS. Αν δεν ήταν να του εγκαταστήσουμε το CentOS, θα το ονομάζαμε κάπως αλλιώς. Να, ένα όνομα που τώρα μας έρχεται στο νου είναι το Keflavíkurflugvöllur. Σημειώστε ότι το όνομα κάθε KVM VM (domain) πρέπει να είναι μοναδικό και να μην περιλαμβάνει λευκούς ή ειδικούς χαρακτήρες.

–description “CentOS 7 64bit”
Δεν είναι υποχρεωτικό να δώσουμε περιγραφή για το VM, όμως είμαστε από εκείνους που πιστεύουν ακράδαντα στις περιγραφές — ειδικά όταν αφορούν σε VMs. Ναι, τέτοιοι είμαστε.

–memory 1024
Το νέο μας VM θα έχει μνήμη μεγέθους 1GB. Είναι ό,τι πρέπει για ένα server-oriented μηχάνημα με Linux. Εννοείται πως αν διαπιστώσουμε ότι το 1 gigabyte είναι λίγο ή πολύ, ανά πάσα στιγμή θα μπορούμε να δώσουμε στο VM περισσότερη μνήμη ή να του ελαττώσουμε την υπάρχουσα.

–cpu host
Προαιρετική παράμετρος. Η CPU του εικονικού υπολογιστή θα έχει χαρακτηριστικά παρόμοια μ’ εκείνα του φυσικού υπολογιστή. Αν σκοπεύουμε να μετακινήσουμε το VM σε host με διαφορετικό επεξεργαστή από εκείνον του τωρινού host, ίσως πρέπει να παραλείψουμε τη συγκεκριμένη παράμετρο.

–vcpus=2
Το VM μας θα έχει δύο εικονικούς επεξεργαστές. Ακριβέστερα: Λόγω της προηγουμένης παραμέτρου, θα έχει έναν επεξεργαστή με δύο πυρήνες.

–network bridge=br0,model=virtio
Για την εικονική μηχανή ζητάμε bridged networking. Μπορούμε να φανταζόμαστε ότι το VM θα έχει μια εικονική κάρτα Ethernet που θα παίρνει IP από τον DHCP server του φυσικού τοπικού δικτύου. Η παράμετρος virtio για το model σημαίνει αυξημένες επιδόσεις στη δικτυακή επικοινωνία μεταξύ διαφορετικών VMs, κάτι που το έχουμε διαπιστώσει και στην πράξη με απλές μετρήσεις (και με τη βοήθεια του iperf).

–disk /var/lib/libvirt/images/husavik.img,bus=virtio
Ο δίσκος του VM είναι το sparse RAW file ονόματι husavik.img, κάτω από το /var/lib/libvirt/images. Όπως και πριν, με την κάρτα Ethernet, η παράμετρος virtio για το bus σημαίνει αυξημένες επιδόσεις.

–cdrom /home/cvar/Downloads/ISOs/CentOS\ 7\ x86_64-Minimal-1511.iso
Στον εικονικό οδηγό CD της μηχανής είναι σαν να έχουμε βάλει ένα δισκάκι με το CentOS (έκδοση 7, εκδοχή 64bit). Εξ ορισμού, κατά την πρώτη ενεργοποίηση της μηχανής το boot γίνεται από τον εικονικό οδηγό CD. Πρακτικά, αυτό σημαίνει ότι κατά την πρώτη ενεργοποίηση θα ξεκινήσει η εγκατάσταση του guest OS.

–noautoconsole
Χάρη σ’ αυτή την παράμετρο, αμέσως μετά τη δημιουργία της μηχανής, ναι μεν αυτή θα ενεργοποιηθεί, αλλά δεν θα επιχειρηθεί το άνοιγμα κάποιας κονσόλας. Στην περίπτωσή μας, εξαιτίας α) της απομακρυσμένης σύνδεσης, β) του sudo και γ) των προεπιλογών ασφαλείας του openSUSE, το άνοιγμα της κονσόλας ούτως ή άλλως θα αποτύγχανε. Σε κάθε περίπτωση το VM ενεργοποιείται, bootάρει από το CD (ISO image) εγκατάστασης του CentOS και μας περιμένει ώστε, με κάποιον τρόπο, να προχωρήσουμε με την εγκατάσταση του OS. Όπως είδαμε στην προηγούμενη ενότητα, ο χρήστης cvar είναι στο group libvirt κι αυτό σημαίνει ότι μπορεί να τρέχει τον Virtual Machine Manager χωρίς sudo, ακόμη κι απομακρυσμένα, και ν’ ανοίγει κονσόλες προς ένα ή περισσότερα VMs.

Θεσπέσια.

Τροποποίηση υπαρχόντων KVM VMs
Κατά τα αναμενόμενα, για την τροποποίηση των ιδιοτήτων ενός KVM VM δεν είναι ανάγκη να καταφύγουμε στον Virtual Machine Manager. Κάλλιστα μπορούμε να εργαστούμε από τη γραμμή εντολών του τερματικού μας. Ας υποθέσουμε, π.χ., ότι θέλουμε να τροποποιήσουμε την ποσότητας της μνήμης του VM με όνομα CentOS. Ξεκινάμε με ένα shutdown της μηχανής:

<br />
cvar@thehost:~&gt; sudo virsh shutdown CentOS<br />
Domain CentOS is being shutdown<br />
cvar@thehost:~&gt;<br />

Το VM ενδέχεται να μην κλείσει ακαριαία, οπότε πριν προχωρήσουμε ας βεβαιωθούμε για την κατάστασή του:

<br />
cvar@thehost:~&gt; sudo virsh list --all<br />
 Id    Name                           State<br />
----------------------------------------------------<br />
 1     Plex                           running<br />
 25    DbxNode                        running<br />
 -     CentOS                         shut off<br />
 -     FreeBSD                        shut off<br />
 -     OpenBSD                        shut off<br />
cvar@thehost:~&gt;<br />

Ωραία, έχει κλείσει. Τα χαρακτηριστικά των VMs αποθηκεύονται σε αρχεία XLM (ένα XML για κάθε VM), τα οποία κατοικούν κάτω από τον κατάλογο /etc/libvirt/qemu. Τα εν λόγω αρχεία δεν τα ανοίγουμε απευθείας, ρίξτε όμως μια ματιά στον σχετικό κατάλογο:

<br />
cvar@thehost:~&gt; sudo ls -lh /etc/libvirt/qemu<br />
total 32K<br />
drwxr-xr-x 1 root root   38 Jan 17 08:04 autostart<br />
-rw------- 1 root root 4.4K Jan 16 21:59 CentOS.xml<br />
-rw------- 1 root root 4.1K Jan 16 21:48 DbxNode.xml<br />
-rw------- 1 root root 4.0K Dec 24 21:24 FreeBSD.xml<br />
drwx------ 1 root root   40 Dec  9 19:23 networks<br />
-rw------- 1 root root 3.9K Dec 12 18:06 OpenBSD.xml<br />
-rw------- 1 root root 4.8K Jan  8 22:31 Plex.xml<br />
cvar@thehost:~&gt;<br />

Θέλουμε να τροποποιήσουμε το CentOS.xml και για να το πετύχουμε γράφουμε

<br />
cvar@thehost:~&gt; sudo virsh edit CentOS<br />

(χωρίς την κατάληξη .xml). Ανοίγει τότε, στον προεπιλεγμένο text editor, το αρχείο XML της μηχανής. Ρίχνοντας μια ματιά στο αρχείο είναι εύκολο να διακρίνουμε τις βασικές παραμέτρους του VM. Ειδικά για τη μνήμη RAM, εστιάζουμε την προσοχή μας πάνω πάνω στο αρχείο και συγκεκριμένα στα δύο μπλοκ ονόματι memory unit και currentMemory unit.

Τροποποίηση της ποσότητας μνήμης ενός από τα VM μας, με απευθείας επέμβαση στο αντίστοιχο αρχείο XML.

Τροποποίηση της ποσότητας μνήμης ενός από τα VM μας, με απευθείας επέμβαση στο αντίστοιχο αρχείο XML.

Προσέξτε ότι και στα δύο μπλοκ η μονάδα μέτρησης είναι το KiB. Πρόκειται για το Kibibyte (δεν έχει γίνει λάθος πληκτρολόγησης) και 1 KiB = 2^10 bytes = 1024 bytes. Στην πληροφορική βέβαια και το KB (Kilobyte) έχουμε συνηθίσει να το ταυτίζουμε με 1024 bytes, επειδή όμως γενικά ισχύει Kilo = 1000 είναι καλό να γράφουμε KiB κι όχι KB. Παρατηρούμε τώρα ότι η RAM του VM είναι 1048576KiB. Διαφορετικά, διαιρώντας με 1024, έχουμε 1024MiB. To MiB είναι το λεγόμενο Mebibyte και ισχύει 1 MiB = 1024 KiB. Πολύ συνχά, στην καθομιλουμένη ή και στο γραπτό λόγο, λέμε ή γράφουμε Megabyte κι εννοούμε Mebibyte κι όλοι καταλαβαινόμαστε και χαιρόμαστε. Τώρα όμως που ανοίξαμε το CentOS.xml και πέσαμε πάνω στο KiB, πιστεύουμε ότι είναι καλό να θυμηθούμε τι πραγματικά σημαίνουν οι διάφορες μονάδες μέτρησης. Το VM μας, λοιπόν, έχει 1024MiB RAM ή αλλιώς 1GiB RAM (Gibibyte). Για να προσθέσουμε άλλο μισό GiB, τις δύο παρουσίες του 1048576 τις κάνουμε 1572864 (=1,5GiB). Αν θέλουμε να αφαιρέσουμε 256MB (για την ακρίβεια 256MiB), τότε τις δύο παρουσίες του 1048576 τις κάνουμε 786432 (=768MiB). Αποθηκεύουμε τις αλλαγές μας κι εγκαταλείπουμε τον editor. Την επόμενη φορά που θα ενεργοποιήσουμε το VM με το CentOS, π.χ., με ένα

<br />
cvar@thehost:~&gt; sudo virsh start CentOS<br />

η μνήμη του θα είναι αλλαγμένη ή, γενικότερα, θα ισχύουν οι όποιες τροποποιήσεις κάναμε προηγουμένως. Σημειώστε ότι αλλαγές στα αρχεία XML των μηχανών επιτρέπεται να κάνουμε ακόμη κι όταν αυτές είναι ενεργές. Απλά, μετά το “sudo virsh edit CentOS” (στη θέση του “CentOS” βάλτε το όνομα του VM σας) θα πρέπει να πληκτρολογούμε τα ακόλουθα:

<br />
cvar@thehost:~&gt; sudo su<br />
thehost:/home/cvar # cd /etc/libvirt/qemu<br />
thehost:/etc/libvirt/qemu # virsh define CentOS.xml<br />
Domain CentOS defined from CentOS.xml<br />
thehost:/etc/libvirt/qemu # exit<br />
exit<br />
cvar@thehost:~&gt;<br />

Οι αλλαγές θα ληφθούν υπόψη την επόμενη φορά που το VM θα ενεργοποιηθεί (όχι μετά από reboot, αλλά μετά από shutdown και power-up). Να προσθέσουμε εδώ ότι όποτε θέλουμε να ελέγξουμε τα βασικά χαρακτηριστικά ενός VM, αρκεί να πληκτρολογούμε κάτι σαν

<br />
cvar@thehost:~&gt; sudo virsh dominfo CentOS<br />
Id:             -<br />
Name:           CentOS<br />
UUID:           41794bb2-c8e8-43aa-98c4-cfa64dfe2aab<br />
OS Type:        hvm<br />
State:          shut off<br />
CPU(s):         2<br />
Max memory:     524288 KiB<br />
Used memory:    524288 KiB<br />
Persistent:     yes<br />
Autostart:      disable<br />
Managed save:   no<br />
Security model: apparmor<br />
Security DOI:   0<br />
cvar@thehost:~&gt;<br />

Άνω τελεία
Υπάρχουν πάρα πολλά ακόμα που θα μπορούσαμε να γράψουμε και να δείξουμε περί του virtualization με το KVM. Σκεφτείτε, π.χ., ότι δεν έχουμε πει τίποτε για το migration, το snapshotting ή το pool management. Το πιθανότερο είναι να επανέλθουμε. Προς το παρόν σας προτείνουμε ν’ ασχοληθείτε κι εσείς. Για οτιδήποτε θελήσετε, μη διστάσετε να επικοινωνήσετε μαζί μας. Από τις όποιες συζητήσεις κάνουμε θα εξαρτηθεί σε μεγάλο βαθμό το πότε θα επανέλθουμε – βεβαίως, και τα θέματα που θα μας απασχολήσουν.

2 Responses to “To KVM για αληθινούς administrators”

  1. sip03ds | 20/01/2016 at 23:05

    Θελουμε και configuration με oVirt

  2. panos986 | 07/06/2016 at 14:43

    Χαιρετώ.
    Ήθελα να ρωτήσω πως μπορώ να έχω δικτύωση τύπου bridged ή host-only με χρήση του virt-manager για έναν windows guest με host fedora.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

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