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

Προσωπικό cloud με το openSUSE, μέρος 2

Χάρη στο openSUSE μετατρέψαμε ένα μάλλον αδιάφορο PC σε ένα σύγχρονο κι ευέλικτο workstation. Ως τώρα φανταζόμαστε πως κι εσείς θα έχετε εξοικειωθεί κάπως με το ολοκαίνουργιο σύστημά σας. Προτείνουμε λοιπόν να μην καθυστερήσουμε άλλο και να προβούμε τώρα στις απαραίτητες ενέργειες, ώστε να του χαρίσουμε ικανότητες virtualization host. Εκτός από την εγκατάσταση της απαραίτητης υποδομής, θα δούμε βεβαίως και πώς δημιουργούμε και διαχειριζόμαστε εικονικές μηχανές.

Πριν περάσουμε στο κυρίως θέμα θα θέλαμε να κάνουμε μια σύντομη σημείωση για τη δικτύωση του PC. Μετά την εγκατάστασή του, το openSUSE είναι έτσι προρυθμισμένο ώστε να ζητά διεύθυνση IP από τον όποιο διαθέσιμο DHCP server. Αν ο name server του τοπικού μας δικτύου είναι στοιχειωδώς ευέλικτος, θα μπορούμε εύκολα να φτάνουμε στο PC γνωρίζοντας μόνο το όνομά του (hostname) κι αγνοώντας εντελώς την αριθμητική διεύθυνση IP. Από τη στιγμή όμως που έχουμε να κάνουμε με μηχάνημα σε ρόλο server, δεν είναι κακή ιδέα να μεριμνήσουμε ώστε να του αποδίδεται πάντοτε το ίδιο IP. Για να πετύχουμε αυτό το αποτέλεσμα δεν χρειάζεται –και δεν προτείνεται– να επέμβουμε στις παραμέτρους δικτύωσης του openSUSE: Αρκεί να επέμβουμε στις ρυθμίσεις του DHCP server που τρέχει ο router μπροστά από το PC.

DHCP static mapping για τον virtualization host.

Μετά από αλλεπάλληλες συσκέψεις μεταξύ των συνεργατών του περιοδικού κι ανυπολόγιστη κατανάλωση φαιάς ουσίας, στον ολοκαίνουργιο virtualization host της Parabing Creations αποφασίσαμε να χαρίσουμε το όνομα thehost. Ναι, δεν πρόκειται για τυπογραφικό: thehost. Ακριβέστερα, το πλήρες όνομά του είναι thehost.colder.xyz και, παρεμπιπτόντως, ο DHCP server του router πάντοτε του δίνει την αριθμητική διεύθυνση 192.168.10.245. Και Τώρα Ξέρετε (TM).

Υποδομή virtualization
Η τεχνολογία virtualization που θα χρησιμοποιεί ο server μας είναι αυτή του KVM (Kernel-based Virtual Machine). Από την έκδοση 2.60.20 του Linux kernel και μετά, ο κώδικας του KVM περιλαμβάνεται στον πυρήνα. Υπάρχει και το user-space μέρος του KVM, το οποίο συμπεριλαμβάνεται στον πανίσχυρο εξομοιωτή ονόματι QEMU. Το KVM κάνει δυνατή την εκτέλεση αυτόνομων εικονικών μηχανών, καθεμία από τις οποίες έχει το δικό της εικονικό hardware (δίσκος, κάρτα δικτύου, κάρτα γραφικών κ.ο.κ.) κι ως guest OS τρέχει Linux, Windows ή BSD. Σε σύγκριση εξάλλου με την τεχνολογία virtualization του Xen, το KVM δεν απαιτεί τροποποιημένη εκδοχή του πυρήνα για να λειτουργήσει. Σε μετρήσεις που γίνονται μεταξύ KVM και Xen, οι εικονικές μηχανές του KVM συχνά εμφανίζονται ελαφρώς γρηγορότερες από εκείνες του Xen. Είναι επίσης σημαντικό ν’ αναφέρουμε ότι η τεχνολογία του KVM έχει αναδειχθεί στην πλέον δημοφιλή στο cloud. Το VPS σας, μ’ άλλα λόγια, είναι πιθανό ν’ αποτελεί ένα KVM VM.

Στο openSUSE μας, ένας τρόπος ώστε να προετοιμαστεί η όλη υποδομή του KVM, μ’ άλλα λόγια να εγκατασταθούν τα απαραίτητα εργαλεία και οι βιβλιοθήκες, καθώς και να τροποποιηθεί το υποσύστημα δικτύωσης του host OS, είναι με τη βοήθεια του YaST. Δείτε τα ακόλουθα screenshots και διαβάστε τις αντίστοιχες περιγραφές.

Εγκατάσταση υποδομής virtualization με τη βοήθεια του YaST.

Μέσα από το YaST πηγαίνουμε στην κατηγορία Virtualization κι εκεί επιλέγουμε το Install Hypervizor and Tools. Εμφανίζεται τότε ένα νέο παράθυρο. Στην ενότητα KVM Hypervizor τσεκάρουμε τα KVM server και KVM tools. Προαιρετικά, στην ενότητα libvirt LXC containers τσεκάρουμε και το libvirt LXC daemon. Τα λεγόμενα LXCs (LinuX Containers) συγγενεύουν με τα FreeBSD jails, αποτελούν μια μορφή “ελαφριού” virtualization κι επιτρέπουν την εκτέλεση αυτόνομων συστημάτων Linux κάτω από τον ίδιο Linux host. Για να ξεκινήσει η εγκατάσταση της υποδομής virtualization αρκεί ένα κλικ στο κουμπί Accept.

Χάρη στο network bridge τα KVM VMs είναι σε θέση να παίρνουν διευθύνσεις IP και από τον τοπικό (φυσικό) DHCP server.

Το YaST μάς ζητά άδεια για να δημιουργήσει ένα network bridge — και προτείνεται να του τη δώσουμε. Έτσι, οι εικονικές μας μηχανές θα είναι σε θέση να λαμβάνουν διευθύνσεις IP απευθείας από τον router του τοπικού δικτύου στον οποίο κατοικεί ο host.

Το μηχάνημα μόλις μετατράπηκε σε έναν ικανότατο virtualization host.

Μετά από λίγα λεπτά το YaST θα έχει ολοκληρώσει τις εργασίες του και το μηχάνημά μας θα έχει μετατραπεί σε έναν ικανότατο virtualization host.

Γνωριμία με τον Virtual Machine Manager
Η δημιουργία και η διαχείριση εικονικών μηχανών είναι δυνατόν να γίνονται από τη γραμμή εντολών. Για όσους όμως τώρα ξεκινούν με το KVM, μια εφαρμογή για το περιβάλλον γραφικών όπως ο Virtual Machine Manager είναι σίγουρα προτιμότερη. Η εν λόγω εφαρμογή εγκαταστάθηκε πριν λίγο, από το YaST. Το όνομα του εκτελέσιμου είναι virt-manager και το πληκτρολογούμε είτε στη γραμμή εντολών είτε στη θυρίδα αναζήτησης του GNOME desktop. Σε κάθε περίπτωση θα μας ζητηθεί να πληκτρολογήσουμε το password του χρήστη μας. Φυσικά, το εικονίδιο του Virtual Machine Manager μπορούμε να το έχουμε στην αριστερή κάθετη μπάρα του GNOME.

Το κεντρικό παράθυρο του Virtual Machine Manager της εγκατάστασής μας, στο οποίο φαίνονται δύο ενεργές εικονικές μηχανές.

Το κεντρικό παράθυρο του Virtual Machine Manager της εγκατάστασής μας, στο οποίο φαίνονται δύο ενεργές εικονικές μηχανές.

Παρατηρώντας για πρώτη φορά τον Virtual Machine Manager πιθανώς να μας φανεί φτωχικός και μάλλον δεν θα μας κερδίσει. Ωστόσο η εφαρμογή παρέχει μεγάλη ευκολία αλλά και ευελιξία. Ο καλύτερος τρόπος για να το διαπιστώσουμε είναι δημιουργώντας μια εικονική μηχανή. Στο πλαίσιο του παραδείγματος που ακολουθεί, το VM που φτιάχνουμε για λειτουργικό σύστημα (guest OS) έχει το Ubuntu Server 14.04.3 LTS 64bit. Πριν ξεκινήσουμε οφείλουμε φυσικά να έχουμε κατεβάσει το αντίστοιχο ISO image. Δείτε τα screenshots και διαβάστε τις αντίστοιχες περιγραφές.

Η δημιουργία νέου KVM VM μέσα από τον Virtual Machine Manager αποτελεί διαδικασία 5 μόλις βημάτων.

Η δημιουργία μιας νέας εικονικής μηχανής ξεκινά με κλικ στο σχετικό εικονίδιο, πάνω αριστερά και κάτω από το μενού του Virtual Machine Manager. Ανοίγει τότε ένα νέο παράθυρο, το οποίο ουσιαστικά αποτελεί έναν βήμα-προς-βήμα οδηγό. Όπως βλέπετε κι εσείς, όλα τα βήματα είναι μόλις πέντε. Καλό αυτό. Στο πρώτο βήμα οφείλουμε να υποδείξουμε το ISO image του λειτουργικού συστήματος που θα έχει η μηχανή. Το έχουμε ήδη κατεβάσει στον host, οπότε επιλέγουμε το Local install media (ISO image or CDROM). Το λειτουργικό μας θα είναι 64bit, επομένως η μηχανή πρέπει να έχει την ανάλογη αρχιτεκτονική. Θέτουμε, λοιπόν, Architecture = x86_64 κι ακολούθως κάνουμε ένα κλικ στο κουμπάκι Forward, κάτω δεξιά.

Διαβάζοντας το ISO image, ο Virtual Machine Manager συχνά καταλαβαίνει από μόνος του τον τύπου του guest OS που θα έχει το VM.

Στο δεύτερο βήμα υποδεικνύουμε τη θέση του ISO image του Ubuntu Server, με κλικ στο Browse. Όσον αφορά στον τύπο του λειτουργικού συστήματος που θα έχει το νέο VM, παρατηρήστε ότι έχουμε τσεκάρει το Automatically detect operating system based on install media. Με τη συγκεκριμένη επιλογή λέμε στον Virtual Machine Manager να προσπαθήσει και να βρει τον τύπο του λειτουργικού αυτόματα, βασιζόμενος στα περιεχόμενα του μέσου εγκατάστασης. Αν δεν τα καταφέρει ή τέλος πάντων διαπιστώσουμε ότι δεν έκανε και πολύ καλή δουλειά, αποεπιλέγουμε το Automatically detect… κι από τα OS type και Version καθορίζουμε μόνοι μας το λειτουργικό. Είναι πιθανό να διαπιστώσουμε ότι δεν παρέχεται ακριβής επιλογή για τον τύπο ή για την έκδοση του λειτουργικού που θα έχει το VM μας. Σε μια τέτοια περίπτωση δεν πρέπει να πτοηθούμε κι αρκεί να καθορίσουμε τον πιο κοντινό τύπο ή την πιο κοντινή έκδοση. Παράδειγμα: Για ένα KVM VM με guest OS το OpenBSD 5.8 64bit, εμείς θέσαμε OS Type = UNIX και Version = OpenBSD 5.6. Όλα πήγαν καλά, περιττό να σημειώσουμε.

Προσθήκη νέου pool με ISO images λειτουργικών συστημάτων προς εγκατάσταση κι επιλογή του ISO για το VM που τώρα δημιουργούμε.

Πριν λίγο, πατώντας στο Browse για να επιλέξουμε το ISO image του Ubuntu, δεν εμφανίστηκε ένα τυπικό παράθυρο του file manager αλλά εκείνο που χρησιμοποιεί ο Virtual Machine Manager για τη διαχείριση των λεγόμενων pools. Ένα pool δεν είναι τίποτε άλλο από έναν τοπικό ή απομακρυσμένο χώρο αποθήκευσης. Σε ένα pool αποθηκεύουμε είτε ISO images λειτουργικών συστημάτων είτε τα αρχεία-εικονικούς δίσκους των VMs. Ανά πάσα στιγμή πρέπει να είναι ορισμένο τουλάχιστον ένα pool και σε κάθε pool επιτρέπεται να βρίσκονται αρχεία και των δύο κατηγοριών. Για λόγους καλής οργάνωσης, πάντως, τέτοια ανακατεμένα (και φρικαλέα) pools προτείνεται να τα αποφεύγουμε. Μετά την εγκατάσταση της υποδομής virtualization υπάρχει ορισμένο ακριβώς ένα pool, ονόματι default, το οποίο ουσιαστικά είναι ο κατάλογος /var/lib/libvirt/images του host. Το συγκεκριμένο pool εμείς το χρησιμοποιούμε αποκλειστικά για την αποθήκευση των εικονικών δίσκων των VMs. Παρεμπιπτόντως, σε ένα KVM VM είναι δυνατόν να δώσουμε απευθείας πρόσβαση σε διαμέρισμα φυσικού δίσκου ή σε ολόκληρο φυσικό δίσκο. Κατά τα αναμενόμενα, σ’ αυτές τις περιπτώσεις δεν δημιουργείται κάποιο αρχείο, σε κανένα pool. Περισσότερα επί του θέματος θα δούμε αργότερα. Επιστρέφοντας στο προκείμενο, εκτός από το default εμείς χρησιμοποιούμε κι ένα pool που έχουμε ονομάσει Images. Σ’ αυτό κρατάμε τα ISO images διαφόρων λειτουργικών συστημάτων που έχουμε κατεβάσει. Στην πραγματικότητα πρόκειται για τον κατάλογο ~/Downloads/Images, μέσα στον προσωπικό κατάλογο του χρήστη μας. Τώρα, για να ορίσουμε ένα νέο pool ξεκινάμε με κλικ στο κουμπάκι [+], κάτω αριστερά (1). Στο νέο παράθυρο που εμφανίζεται δίνουμε ένα όνομα για το νέο pool (θυρίδα Name), ενώ καθορίζουμε και τον τύπο του (επιλογή Type): για έναν τοπικό κατάλογο θέτουμε “Type = dir: Filesystem Directory”. Πατάμε στο κουμπί Forward και με κλικ στο Browse (2) υποδεικνύουμε τη διαδρομή του τοπικού καταλόγου που αντιστοιχεί στο pool. Με κλικ στο Finish το παράθυρο Add a New Storage Pool κλείνει, και το όνομα του νέου pool εμφανίζεται στη σχετική λίστα του pool manager (3). Το pool φροντίζουμε ώστε να ‘ναι επιλεγμένο, κι από το πλαίσιο δεξιά (4) διαλέγουμε το επιθυμητό ISO image. Πατάμε τέλος στο Choose Volume (5) κι έτσι καθορίζεται το ISO image από το οποίο θα γίνει η εγκατάσταση του guest OS για το VM μας.

Αυτόματος εντοπισμός τύπου guest OS, καθορισμός μνήμης RAM κι αριθμού επεξεργαστών για το VM, προετοιμασία και για τον καθορισμό εικονικού δίσκου.

Αφού υποδείξαμε το ISO image του Ubuntu Server, παρατηρούμε ότι ο Virtual Machine Manager κατάφερε να θέσει σωστά, από μόνος του, τον τύπο και την έκδοση του guest OS (1). Στα επόμενα βήματα έχουμε την ευκαιρία να καθορίσουμε την ποσότητα της μνήμης RAM, καθώς και τον αριθμό των εικονικών επεξεργαστών του VM (2). Στη συνέχεια ασχολούμαστε με τον εικονικό ή τους εικονικούς δίσκους της μηχανής. Αρχικά, φροντίζουμε ώστε το Enable storage for this virtual machine να είναι τσεκαρισμένο. Είναι δυνατόν να δώσουμε εδώ, απευθείας, το μέγεθος του δίσκου, και ν’ αφήσουμε τον Virtual Machine Manager να φροντίσει για τα υπόλοιπα (Create a disk image on the computer’s hard drive). Αν όμως θέλουμε ν’ αποκτήσουμε μια καλή εικόνα για τις δυνατότητες διαχείρισης storage που μας παρέχονται, επιλέγουμε το Select managed or other existing storage και κάνουμε ένα κλικ στο κουμπί Browse, από κάτω (3).

Δημιουργία δυναμικού εικονικού δίσκου τύπου RAW, με άνω όριο μεγέθους τα 64GB.

Για άλλη μια φορά ανοίγει το παράθυρο διαχείρισης των pools του Virtual Machine Manager. Για να φτιάξουμε τον εικονικό δίσκο της μηχανής επιλέγουμε το pool ονόματι default (1) και κάνουμε ένα κλικ στο κουμπάκι [+], στα δεξιά του Volumes (2). Θα ανοίξει ένα μικρό παράθυρο με τον τίτλο Add a Storage Volume. Στη θυρίδα Name δίνουμε το όνομα του αρχείου-εικονικού δίσκου κι από κάτω, στο Format, επιλέγουμε τον τύπο του (3). Ο προεπιλεγμένος τύπος για τα αρχεία-εικονικούς δίσκους είναι ο qcow2 και μεταξύ άλλων επιτρέπει τα snapshots, τη συμπίεση και την κρυπτογράφηση. Αν ενδιαφερόμαστε περισσότερο για τις επιδόσεις κι όχι για τις δυνατότητες, τότε ο τύπος raw είναι ό,τι πρέπει. Στη θυρίδα Max Capacity, εξάλλου, πληκτρολογούμε το μέγιστο επιθυμητό μέγεθος του εικονικού δίσκου, ενώ στην Allocation το αρχικό του μέγεθος (4). Στο παράδειγμά μας, λοιπόν, ο δίσκος ξεκινά με μηδενικό μέγεθος και μεγαλώνει όποτε κι όσο χρειάζεται, με άνω όριο τα 64GB. Φυσικά, για το guest OS ο δίσκος ανά πάσα στιγμή θα φαίνεται να έχει σταθερό μέγεθος (64GB). Αφού αποφασίσουμε για τις παραμέτρους του δίσκου και τις καθορίσουμε, κάνουμε ένα κλικ στο κουμπάκι Finish. Το αρχείο του εικονικού δίσκου θα εμφανιστεί στο κεντρικό πλαίσιο του διαχειριστή των pools (5). Τώρα, για να αντιστοιχιστεί στο VM τον επιλέγουμε κι αμέσως μετά πατάμε στο κουμπί Choose Volume, κάτω δεξιά.

Το νέο μας VM είναι πρακτικά έτοιμο, αλλά πριν ξεκινήσει η εγκατάσταση του guest OS θέλουμε να ρίξουμε μια ματιά στα υποσυστήματα της εικονικής μηχανής.

Βρισκόμαστε στο 4ο από τα 5 βήματα δημιουργίας VM και μόλις φτιάξαμε τον εικονικό δίσκο της μηχανής. Πατάμε στο κουμπί Forward και μεταβαίνουμε στο 5ο και τελευταίο βήμα. Στη θυρίδα Name δίνουμε ένα όνομα για τη μηχανή, χωρίς κενά (1). Τσεκάρουμε το Customize configuration before install (2), ώστε πριν ξεκινήσει η εγκατάσταση του guest OS να ρίξουμε μια τελευταία ματιά στο hardware του VM. Για τη δικτύωσή του θέτουμε Network selection = Bridge br0: Host device eth0 (3), ώστε στην εικονική κάρτα Ethernet να αντιστοιχιστεί διεύθυνση IP από τον router του (αληθινού) εικονικού δικτύου. Τέλος, πατάμε στο κουμπί Finish.

Ο Virtual Machine Manager παρουσιάζει τα υποσυστήματα της επιλεγμένης μηχανής σε ένα κάθετο πλαίσιο στ' αριστερά του παραθύρου με τις ιδιότητές της.

Σε κάθε εικονική μηχανή μάς παρέχεται λεπτομερής πρόσβαση στο υλικό που την απαρτίζει. Ο Virtual Machine Manager παρουσιάζει τα υποσυστήματα της επιλεγμένης μηχανής σε ένα κάθετο πλαίσιο στ’ αριστερά (1). Όπως φανερώνει το κουμπί Add Hardware, κάτω από το εν λόγω πλαίσιο, είναι δυνατόν να προσθέτουμε υποσυστήματα, όπως, π.χ., εικονικούς δίσκους ή εικονικές κάρτες Ethernet, ακόμη και μετά τη συγκρότηση μιας μηχανής. Μπορούμε επίσης να επιλέγουμε υποσυστήματα και να τα αφαιρούμε. Για παράδειγμα, ένα VM σε ρόλο server μάλλον δεν χρειάζεται εικονική κάρτα ήχου. Καθώς εξετάζουμε τα υποσυστήματα της μηχανής μας –και με δεδομένο ότι μόλις τη φτιάξαμε και δεν έχει guest OS–, όταν είμαστε έτοιμοι πατάμε στο Begin Installation (2) και ξεκινά η εγκατάσταση του λειτουργικού συστήματος (του Ubuntu Server, στο πλαίσιο του παραδείγματός μας). Αλλά ας μην την ξεκινήσουμε αμέσως. Με κλικ πάνω σε κάθε γραμμή του κάθετου πλαισίου αριστερά, στη μεγαλύτερη περιοχή στα δεξιά εμφανίζονται όλες οι λεπτομέρειες που αφορούν στη μηχανή ή στο αντίστοιχο υποσύστημα. Από τη μεριά μας έχουμε δυνατότητα για επεμβάσεις και τροποποιήσεις. Με κλικ πάνω στο Overview, για παράδειγμα, μπορούμε να δώσουμε έναν χαρακτηριστικό τίτλο (3) καθώς και μια λεπτομερή περιγραφή για τη μηχανή (4). Όταν έχουμε λίγα μόνο VMs τέτοιες πληροφορίες δεν φαίνεται να ‘χουν μεγάλη αξία, αυτό όμως αλλάζει καθώς δημιουργούμε νέες μηχανές. Κάθε επέμβαση που πραγματοποιούμε την παγιώνουμε με κλικ στο κουμπί Apply, κάτω δεξιά.

Καθορισμός του πλήθους των εικονικών επεξεργαστών της μηχανής. Με κλικ στο Copy host CPU configuration ο εικονικός επεξεργαστής αποκτά τα χαρακτηριστικά του φυσικού επεξεργαστή.

Καθορισμός του πλήθους των εικονικών επεξεργαστών (1) της μηχανής. Με κλικ στο Copy host CPU configuration (2) ο εικονικός επεξεργαστής αποκτά τα χαρακτηριστικά του φυσικού επεξεργαστή.

Στη μηχανή μας έχουμε δώσει 1GB μνήμης RAM. Αν διαπιστώσουμε ότι είναι λιγότερη ή περισσότερη απ' όση πραγματικά χρειάζεται, ερχόμαστε εδώ κι αλλάζουμε την ποσότητα της RAM (η μηχανή πρέπει να είναι κλειστή).

Στη μηχανή μας έχουμε δώσει 1GB μνήμης RAM. Αν διαπιστώσουμε ότι είναι λιγότερη ή περισσότερη απ’ όση πραγματικά χρειάζεται, ερχόμαστε εδώ κι αλλάζουμε την ποσότητα της RAM (η μηχανή πρέπει να είναι κλειστή). Την πρώτη φορά που ξεκινήσαμε ένα VM με 768MB RAM και Ubuntu Server σε ρόλο Dropbox node, διαπιστώσαμε ότι κατά το πρώτο population του φακέλου “Dropbox” η μνήμη εξαντλούταν, ενώ και το SWAP partition γέμιζε. Το αποτέλεσμα ήταν ότι το service του Dropbox τερματιζόταν. Αυξήσαμε τη μνήμη RAM στα 2GB, το πρόβλημα εξαφανίστηκε, η ειρήνη επικράτησε και πάλι στον κόσμο μας.

Θέλουμε η μηχανή μας να ξεκινά αυτόματα, κατά την εκκίνηση του host OS; Αν ναι, απλά τσεκάρουμε την επιλογή Start virtual machine on host boot up.

Θέλουμε η μηχανή μας να ξεκινά αυτόματα, κατά την εκκίνηση του host OS; Αν ναι, απλά τσεκάρουμε την επιλογή Start virtual machine on host boot up. Σημειώστε εδώ ότι η κατάσταση μιας οποιασδήποτε μηχανής (ανενεργή/κλειστή ή ενεργή/ανοικτή) είναι άσχετη με το αν ο Virtual Machine Manager τρέχει ή όχι. Ίσως δεν χρειάζεται καν να το αναφέρουμε, αλλά τώρα που το σκεφτήκαμε το αναφέρουμε ούτως ή άλλως: Τα KVM VMs λειτουργούν ως υπηρεσίες, ενώ ο Virtual Machine Manager αποτελεί μια απλή εφαρμογή διαχείρισής τους.

Η ταχύτερη δυνατή πρόσβαση στο δίσκο της μηχανής επιτυγχάνεται μέσω των VirtIO drivers.

Η ταχύτερη δυνατή πρόσβαση στο δίσκο της μηχανής επιτυγχάνεται μέσω των VirtIO drivers (Disk bus = VirtIO), διαφορετικά μιλάμε για εξομοίωση οδηγών IDE, SATA ή SCSI. Για να δουλέψει η πρόσβαση μέσω VirtIO, το guest OS πρέπει να διαθέτει τους ανάλογους οδηγούς. Στις σύγχρονες διανομές Linux (με πυρήνα 3.8 ή νεότερο) καθώς και στο FreeBSD από την έκδοση 9.0 και μετά, οι εν λόγω οδηγοί είναι παρόντες. Διατίθενται εξάλλου και για Windows, μόνο που εκεί πρέπει να εγκατασταθούν χειροκίνητα.

Από τον εικονικό οδηγό CD του VM απουσιάζει το ISO image του Ubuntu Server. Το έχουμε όμως υποδείξει στον Virtual Machine Manager και, όταν θα κάνουμε κλικ στο Begin Installation (πάνω αριστερά), το ISO image θα προσαρτηθεί αυτόματα και το VM θα εκκινήσει απ' αυτό.

Από τον εικονικό οδηγό CD του VM απουσιάζει το ISO image του Ubuntu Server. Το έχουμε όμως υποδείξει στον Virtual Machine Manager και, όταν θα κάνουμε κλικ στο Begin Installation (πάνω αριστερά), το ISO image θα προσαρτηθεί αυτόματα και το VM θα εκκινήσει απ’ αυτό. Παρατηρήστε εξάλλου το Disk bus: για τον εικονικό οδηγό CD δεν είναι ο VirtIO αλλά ο IDE.

Η μηχανή χρησιμοποιεί bridged networking, γεγονός που σημαίνει ότι θα πάρει διεύθυνση IP από τον φυσικό router του τοπικού δικτύου.

Η μηχανή χρησιμοποιεί bridged networking, γεγονός που σημαίνει ότι θα πάρει διεύθυνση IP από τον φυσικό router του τοπικού δικτύου. Παρατηρήστε ότι για την πρόσβαση στην κάρτα Ethernet του host έχει επιλεγεί ο οδηγός VirtIO. Τη συγκεκριμένη επιλογή την έκανε για εμάς ο Virtual Machine Manager, με βάση το guest OS του VM. Για άλλα guest OSes, για τα οποία δεν διατίθεται ο VirtIO driver, εξομοιώνεται κάποιο γνωστό μοντέλο κάρτας Ethernet. Παρατηρήστε εξάλλου ότι φαίνεται και η διεύθυνση MAC της εικονικής κάρτας δικτύου. Αν θέλουμε μπορούμε από τώρα να τη δώσουμε στον DHCP server του (φυσικού) router, ώστε το VM μας να παίρνει πάντοτε την ίδια διεύθυνση IP.

Ένα υποσύστημα που σίγουρα δεν χρειάζεται στα VMs σε ρόλο server, είναι η κάρτα ήχου.

Ένα υποσύστημα που σίγουρα δεν χρειάζεται στα VMs σε ρόλο server, είναι η κάρτα ήχου. Η απομάκρυνση εικονικού hardware δεν θα μπορούσε να γίνεται ευκολότερα, μέσα από τον Virtual Machine Manager.

Το VM έχει ενεργοποιηθεί και η εγκατάσταση του guest OS (Ubuntu Server) προχωρά κανονικά.

Το VM έχει ενεργοποιηθεί και η εγκατάσταση του guest OS (Ubuntu Server) προχωρά κανονικά. Με κλικ μέσα στο παράθυρο της μηχανής, το focus πληκτρολογίου και ποντικιού μεταφέρεται στο guest OS. Για να επανέλθει στο host OS πατάμε τα πλήκτρα [Ctrl] και [Alt], ταυτόχρονα.

Από ένα παράθυρο τερματικού ρίχνουμε μια ματιά στον κατάλογο /var/lib/libvirt/images, στον οποίο εξ ορισμού κατοικούν οι εικονικοί δίσκοι των VMs. Βλέπουμε τρία αρχεία και τα αντίστοιχα μεγέθη τους. Συνολικά, τα αρχεία μέσα στον images θα έπρεπε να έχουν μέγεθος 64+64+32 = 160 gigabytes. Στην πραγματικότητα, όμως, τη στιγμή που ελήφθη το screenshot καταλάμβαναν μόλις 18GB. Αυτά είναι τα καλά των εικονικών δίσκων, που μεγαλώνουν δυναμικά!

Από ένα παράθυρο τερματικού ρίχνουμε μια ματιά στον κατάλογο /var/lib/libvirt/images, στον οποίο εξ ορισμού κατοικούν οι εικονικοί δίσκοι των VMs. Βλέπουμε τρία αρχεία και τα αντίστοιχα μεγέθη τους. Συνολικά, τα αρχεία μέσα στον images θα έπρεπε να έχουν μέγεθος 64+64+32 = 160 gigabytes. Στην πραγματικότητα, όμως, τη στιγμή που ελήφθη το screenshot καταλάμβαναν μόλις 18GB. Αυτά είναι τα καλά των εικονικών δίσκων, που μεγαλώνουν δυναμικά!

Μετά την εγκατάσταση του Ubuntu Server (Trusty Tahr) μάς άνοιξε η όρεξη και είπαμε να φτιάξουμε άλλο ένα VM, με το αγαπημένο μας FreeBSD. Τη στιγμή του screenshot υπήρχαν τέσσερα VMs ενεργά και, όπως βλέπετε κι από το System Monitor του GNOME, το host computer δεν ζοριζόταν ιδιαίτερα.

Μετά την εγκατάσταση του Ubuntu Server (Trusty Tahr) μάς άνοιξε η όρεξη και είπαμε να φτιάξουμε άλλο ένα VM, με το αγαπημένο μας FreeBSD. Τη στιγμή του screenshot υπήρχαν τέσσερα VMs ενεργά και, όπως βλέπετε κι από το System Monitor του GNOME, το host computer δεν ζοριζόταν ιδιαίτερα.

Αντιστοίχιση φυσικού δίσκου σε VM
Μερικές φορές, κι αναλόγως του ρόλου που έχει μια εικονική μηχανή, είναι χρήσιμο να της δίνουμε αληθινούς (φυσικούς) δίσκους ή διαμερίσματα αληθινών δίσκων. Αυτό αποφασίσαμε να κάνουμε για ένα KVM VM με Ubuntu Server, που χρησιμοποιούμε ως Dropbox node. Τι εννοούμε; Θα σας πούμε αμέσως. Διαθέτουμε λογαριασμό Dropbox Pro τους ενός terabyte, ο οποίος αυτή τη στιγμή έχει γύρω στα 270GB. Όλον αυτόν τον όγκο των δεδομένων δεν τον θέλουμε στον SSD του laptop, χωρητικότητας 512GB, θέλουμε ωστόσο ένα τοπικό μηχάνημα το οποίο ανά πάσα στιγμή θα έχει όλα τα δεδομένα που βρίσκονται online, στο Dropbox μας. Στο σχετικό VM θα μπορούσαμε να δώσουμε έναν εικονικό δίσκο με άνω όριο μεγέθους το 1ΤΒ. Ένα τέτοιο αρχείο όμως δεν θα ήταν και πολύ βολικό, ειδικά αν επρόκειτο να μεταφερθεί σε διαφορετικό φυσικό host. Αγοράσαμε, λοιπόν, έναν φυσικό δίσκο του 1TB, το προσθέσαμε στο host computer και στη συνέχεια τον δώσαμε απευθείας στο KVM VM. Χάρη σ’ αυτή τη διευθέτηση, στα δεδομένα του δίσκου έχει πρόσβαση το VM αλλά και το host computer. Επίσης, μπορεί να έχει πρόσβαση κι οποιοσδήποτε άλλος host με Linux — αρκεί να μεταφέρουμε εκεί τον δίσκο. Στο υπόλοιπο του άρθρου δείχνουμε πώς αντιστοιχίσαμε στο VM τον φυσικό μας δίσκο.

Το VM στο οποίο θα δώσουμε τον φυσικό δίσκο ονομάζεται Dropbox Node και, όπως βλέπουμε από τον Virtual Machine Manager, αυτή τη στιγμή είναι κλειστό. Θα παραμείνει έτσι και θα το ξεκινήσουμε αφού προσθέσουμε το δίσκο.

Το VM στο οποίο θα δώσουμε τον φυσικό δίσκο ονομάζεται “Dropbox Node” και, όπως βλέπουμε από τον Virtual Machine Manager, αυτή τη στιγμή είναι κλειστό. Θα παραμείνει έτσι και θα το ξεκινήσουμε αφού προσθέσουμε το δίσκο. Από τις ιδιότητες της μηχανής παρατηρούμε ότι το VM προς το παρόν διαθέτει έναν εικονικό δίσκο, μεγέθους 32GB. Πρόκειται για το δίσκο εγκατάστασης του λειτουργικού συστήματος (Ubuntu Server) και φυσικά για το δίσκο εκκίνησης της μηχανής.

Στο φυσικό σύστημα με το openSUSE τρέχουμε το YaST κι ενεργοποιούμε το module ονόματι Partitioner (βρίσκεται στην κατηγορία Hardware).

Στο φυσικό σύστημα με το openSUSE τρέχουμε το YaST κι ενεργοποιούμε το module ονόματι Partitioner (βρίσκεται στην κατηγορία Hardware).

Το device name του φυσικού δίσκου που θα δώσουμε στο VM, σύμφωνα με το openSUSE είναι το /dev/sda. Το συγκεκριμένο όνομα παράγεται δυναμικά κι ενδέχεται ν' αλλάξει, π.χ., αν βάλουμε το δίσκο σε διαφορετικό port πάνω στη μητρική του PC ή τον μεταφέρουμε σε άλλο PC. Ευτυχώς, κάθε κατασκευαστής αντιστοιχίζει στους δίσκους κάποια ονόματα που μένουν αναλλοίωτα και δεν εξαρτώνται από το port στο οποίο συνδέεται η συσκευή, ούτε από το εκάστοτε λειτουργικό σύστημα.

Στο αριστερό κάθετο πλαίσιο του Partitioner, με τίτλο System View, αναπτύσσουμε το δέντρο δίνοντας thehost –> Hard Disks (το δικό σας σύστημα πιθανώς θα έχει διαφορετικό hostname). Παρατηρούμε ότι το Linux έχει εντοπίσει κι ονομάσει δύο σκληρούς δίσκους, τον sda και τον sdb. Δείτε και το μεγαλύτερο πλαίσιο, με όνομα Hard Disks, στα δεξιά. Στο παράδειγμά μας ο δίσκος sdb έχει δύο διαμερίσματα (partitions): το sdb1 (τύπου Swap) και το sdb2 (τύπου BtrFS). Προφανώς, ο δίσκος sdb είναι εκείνος στον οποίο έχει εγκατασταθεί το openSUSE μας. Ο δε δίσκος sda στερείται διαμερισμάτων κι έχει μέγεθος κοντά στο 1TB. Αυτός ακριβώς είναι ο νέος μας δίσκος, τον οποίο θέλουμε να δώσουμε στο VM με το Ubuntu Server (δηλαδή στο Dropbox Node). Το device name της συσκευής, σύμφωνα με το openSUSE, είναι το /dev/sda. Το θέμα εδώ είναι ότι το συγκεκριμένο όνομα παράγεται δυναμικά κι ενδέχεται ν’ αλλάξει, π.χ., αν βάλουμε το δίσκο σε διαφορετικό port πάνω στη μητρική του PC ή τον μεταφέρουμε σε άλλο PC. Το VM μας, λοιπόν, δεν είναι έξυπνο ν’ αναφέρεται στον φυσικό δίσκο με βάση το δυναμικό του όνομα. Ευτυχώς, κάθε κατασκευαστής αντιστοιχίζει στους δίσκους κάποια ονόματα που μένουν αναλλοίωτα και δεν εξαρτώνται από το port στο οποίο συνδέεται η συσκευή, ούτε από το εκάστοτε λειτουργικό σύστημα.

Στις πληροφορίες που αφορούν στο δίσκο συγκαταλέγονται και τα 'σταθερά' ονόματά του. Πρόκειται για όλα αυτά τα 'Device ID' και είναι έξι στο πλήθος. Ένα οποιοδήποτε εξ αυτών μας κάνει -- κι εμείς εστιάσαμε στο Device ID 2.

Για να δούμε τα στατικά ονόματα του δίσκου μας, στο πλαίσιο System View του Partitioner κάνουμε απλά ένα κλικ στο όνομα της συσκευής κατά Linux (sda). Αμέσως, στο πλαίσιο δεξιά εμφανίζονται πληροφορίες που αφορούν στο δίσκο και μεταξύ αυτών είναι και τα “σταθερά” ονόματά του. Πρόκειται για όλα αυτά τα “Device ID” και είναι έξι στο πλήθος. Ένα οποιοδήποτε εξ αυτών μας κάνει — κι εμείς εστιάσαμε στο Device ID 2.

Χωρίς το YaST και τον Partitioner, τα Device IDs τα βλέπουμε και μέσα στον κατάλογο /dev/disk/by-id. Όλα τα Device IDs που μας ενδιαφέρουν αποτελούν symbolic links προς το όνομα που έχει αποδώσει το Linux στο δίσκο (sda).

Χωρίς το YaST και τον Partitioner, τα Device IDs τα βλέπουμε και μέσα στον κατάλογο /dev/disk/by-id. Όλα τα Device IDs που μας ενδιαφέρουν αποτελούν symbolic links προς το όνομα που έχει αποδώσει το Linux στο δίσκο (sda).

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

Προκειμένου να ενημερώσουμε το VM μας για την παρουσία του φυσικού δίσκου, στον οποίο θέλουμε να έχει απευθείας πρόσβαση, δεν εργαζόμαστε μέσα από τον Virtual Machine Manager. Αντίθετα, κάνουμε συγκεκριμένες προσθήκες στο αρχείο XML που περιγράφει τις ιδιότητες της εικονικής μηχανής. Ανοίγουμε ένα τερματικό κι αποκτούμε δικαιώματα root (1). Μεταβαίνουμε στον κατάλογο /etc/libvirt/qemu (2), αφού σ’ αυτόν διατηρούνται τα αρχεία XML των μηχανών. Βλέποντας τα περιεχόμενα του καταλόγου (3), εύκολα διακρίνουμε το αρχείο στο οποίο πρέπει να επέμβουμε. Για εμάς είναι το DbxNode.xml. Προσέξτε, όμως: Αντί να το ανοίξουμε απευθείας με κάποιον text editor πληκτρολογούμε κάτι σαν “virsh edit DbxNode” (χωρίς τα εισαγωγικά και χωρίς την κατάληξη του αρχείου).

Στην ενότητα devices και προσθέτουμε ένα νέο disk μπλοκ, κάτω από το υπάρχον και σαν αυτό που είναι τονισμένο στο screenshot.

Η εντολή που μόλις δώσαμε ανοίγει το αρχείο DbxNode.xml μέσα από το vi, τον προκαθορισμένο text editor στο openSUSE. Αν δεν είστε εξοικειωμένοι με τον εν λόγω editor κάλλιστα μπορούμε να τον αλλάξουμε, αφού όμως πρώτα τον εγκαταλείψουμε πατώντας [Shift]+[;], γράφοντας “q!” (χωρίς τα εισαγωγικά) και δίνοντας ένα [Enter]. Ένας εύχρηστος και κατά την άποψη του γράφοντα πολύ πιο φιλικός editor, είναι το nano. Σε περίπτωση που δεν είναι εγκατεστημένο στο openSUSE σας, γράψτε “zypper install nano” και μετά πληκτρολογήστε EDITOR=”/usr/bin/nano” virsh edit DbxNode. Όποιος κι αν είναι ο editor, πηγαίνουμε στην ενότητα devices και προσθέτουμε ένα νέο disk μπλοκ, κάτω από το υπάρχον και σαν αυτό που είναι τονισμένο στο screenshot. Προφανώς, το μόνο που θα αλλάξει για τη δική σας περίπτωση είναι το Device ID στη γραμμή. Επίσης, αν το VM σας έχει δύο δίσκους, τότε αυτό το vdb στη γραμμή θα πρέπει να αντικατασταθεί με το vdc. Μετά την προσθήκη του νέου disk μπλοκ στο DbxNode.xml, αποθηκεύουμε τις αλλαγές κι εγκαταλείπουμε τον editor. (Αν χρησιμοποιούμε το nano, δίνουμε [CTRL+O] κι [Enter] για αποθήκευση και μετά ένα [CTRL+X] για έξοδο.)

Η προσθήκη που κάναμε στο DbxNode.xml δεν θα ληφθεί υπόψη αν δεν πληκτρολογήσουμε και virsh define DbxNode.xml. Αν δεν έχουμε κάνει κάποιο λάθος, θα πρέπει να πάρουμε ένα μήνυμα σαν αυτό που απεικονίζεται στο screenshot.

Η προσθήκη που κάναμε στο DbxNode.xml δεν θα ληφθεί υπόψη αν δεν πληκτρολογήσουμε και “virsh define DbxNode.xml” (ναι, αυτή τη φορά με την κατάληξη). Αν δεν έχουμε κάνει κάποιο λάθος, θα πρέπει να πάρουμε ένα μήνυμα σαν αυτό που απεικονίζεται στο screenshot.

Το μήνυμα που πήραμε στο τερματικό δεν μας αρκεί για να βεβαιωθούμε ότι ο δίσκος έχει προστεθεί στο VM. Μέσα από τον Virtual Machine Manager, λοιπόν, ρίχνουμε μια ματιά στις ιδιότητες της μηχανής (για το παράδειγμά μας, εκείνης με όνομα Dropbox Node). Λογικά, τώρα θα έχει δύο δίσκους. Ο δεύτερος (VirtIO Disk 2) είναι ο φυσικός δίσκος που μόλις προσθέσαμε. Δείτε το Source path και θα πειστείτε.

Το μήνυμα που πήραμε στο τερματικό δεν μας αρκεί για να βεβαιωθούμε ότι ο δίσκος έχει προστεθεί στο VM. Μέσα από τον Virtual Machine Manager, λοιπόν, ρίχνουμε μια ματιά στις ιδιότητες της μηχανής (για το παράδειγμά μας, εκείνης με όνομα Dropbox Node). Λογικά, τώρα θα έχει δύο δίσκους. Ο δεύτερος (VirtIO Disk 2) είναι ο φυσικός δίσκος που μόλις προσθέσαμε. Δείτε το Source path και θα πειστείτε.

Ο καλύτερος τρόπος για να βεβαιωθούμε ότι το VM βλέπει το φυσικό δίσκο, είναι να ενεργοποιήσουμε τη μηχανή και να δούμε από μόνοι μας. Στο στιγμιότυπο έχουμε ξεκινήσει το Ubuntu Server KVM VM και με τη βοήθεια του fdisk διαπιστώνουμε ότι, πράγματι, ο δίσκος είναι ορατός από το guest OS.

Εντάξει, ο καλύτερος τρόπος για να βεβαιωθούμε ότι το VM βλέπει το φυσικό δίσκο, είναι να ενεργοποιήσουμε τη μηχανή και να δούμε από μόνοι μας. Στο στιγμιότυπο έχουμε ξεκινήσει το Ubuntu Server KVM VM και με τη βοήθεια του fdisk διαπιστώνουμε ότι, πράγματι, ο δίσκος είναι ορατός από το guest OS.

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

Προκειμένου να χρησιμοποιήσουμε το δίσκο, πρέπει να φτιάξουμε τουλάχιστον ένα διαμέρισμα πάνω του. Προς τούτο καταφεύγουμε στο εργαλείο cfdisk (στην κονσόλα πληκτρολογούμε “sudo cfdisk /dev/vdb”) και δημιουργούμε ακριβώς ένα διαμέρισμα, το οποίο καταλαμβάνει όλο το διαθέσιμο χώρο.

Αφού εγκαταλείψουμε το cfdisk βεβαιωνόμαστε ότι το νέο διαμέρισμα είναι παρόν, πληκτρολογώντας sudo fdisk -l. Στο παράδειγμά μας, το device του νέου διαμερίσματος είναι το /dev/dvb1.

Αφού εγκαταλείψουμε το cfdisk βεβαιωνόμαστε ότι το νέο διαμέρισμα είναι παρόν, πληκτρολογώντας “sudo fdisk -l”. Στο παράδειγμά μας, το device του νέου διαμερίσματος είναι το /dev/dvb1.

Σειρά έχει το format του partition, μ' άλλα λόγια η δημιουργία συστήματος αρχείων (filesystem) για το /dev/dvb1. Το σύστημα αρχείων Ext4 είναι μια χαρά για τις ανάγκες μας και το δημιουργούμε όπως υποδεικνύεται στο στιγμιότυπο (αυτό το wdcBlue1TB είναι το label που επιλέξαμε να δώσουμε στο διαμέρισμα).

Σειρά έχει το format του partition, μ’ άλλα λόγια η δημιουργία συστήματος αρχείων (filesystem) για το /dev/dvb1. Το σύστημα αρχείων Ext4 είναι μια χαρά για τις ανάγκες μας και το δημιουργούμε όπως υποδεικνύεται στο στιγμιότυπο (αυτό το “wdcBlue1TB” είναι το label που επιλέξαμε να δώσουμε στο διαμέρισμα).

Για τη συνέχεια, επειδή θα θέλουμε να αντιγράψουμε *εύκολα* το UUID του νέου διαμερίσματος και να το επικολλήσουμε στο /etc/fstab, αφήνουμε την κονσόλα του Virtual Machine Manager κι από ένα τερματικό του openSUSE κάνουμε SSH login στο Dropbox Node.

Για τη συνέχεια, επειδή θα θέλουμε να αντιγράψουμε εύκολα το UUID του νέου διαμερίσματος και να το επικολλήσουμε στο /etc/fstab, αφήνουμε την κονσόλα του Virtual Machine Manager κι από ένα τερματικό του openSUSE κάνουμε SSH login στο Dropbox Node. Ο λογαριασμός του χρήστη στο παράδειγμά μας, στον οποίο κάνουμε SSH login, έχει ως username το sub0. Χάρη εξάλλου στο pfSense box μπροστά από το KVM VM με το Ubuntu Server, αντί να πληκτρολογήσουμε τη διεύθυνση IP του VM γράψαμε, απλά, dbxnode (αυτό είναι το hostname του).

Κάθε διαμέρισμα ενός οποιουδήποτε δίσκου έχει ένα μοναδικό αναγνωριστικό μήκους 128 bits, που ονομάζεται UUID (από το Universally Unique IDentifier). Στις γραμμές του αρχείου /etc/fstab, με βάση τις οποίες γίνεται η προσάρτηση (mounting) των διαμερισμάτων, καλό είναι να βάζουμε τα σταθερά UUIDs κι όχι τα δυναμικά device names.

Κάθε διαμέρισμα ενός οποιουδήποτε δίσκου έχει ένα μοναδικό αναγνωριστικό μήκους 128 bits, που ονομάζεται UUID (από το Universally Unique IDentifier). Στις γραμμές του αρχείου /etc/fstab, με βάση τις οποίες γίνεται η προσάρτηση (mounting) των διαμερισμάτων, καλό είναι να βάζουμε τα σταθερά UUIDs κι όχι τα δυναμικά device names. (Όσο ένα διαμέρισμα υφίσταται διατηρεί αναλλοίωτο το UUID του, ανεξάρτητα από τη φυσική θέση του δίσκου και τη δυναμική ονομασία που του αποδίδει το λειτουργικό σύστημα.) Ένας τρόπος για να μαθαίνουμε τα UUIDs των διαμερισμάτων είναι με μια ματιά στα περιεχόμενα του καταλόγου /dev/disk/by-uuid. Στο screenshot, το UUID που μας ενδιαφέρει αποτελεί symbolic link προς το /dev/vdb1 (ή προς το ../../vdb1, σε σχέση με τον κατάλογο /dev/disk/by-uuid). Καλό είναι να επιλέξουμε το UUID με το ποντίκι και να το αντιγράψουμε με δεξί κλικ και Copy.

Σειρά έχει η τροποποίηση του αρχείου fstab στον κατάλογο /etc, το οποίο ανοίγουμε με δικαιώματα υπερχρήστη και με τη βοήθεια του nano. Θα προσθέσουμε στο αρχείο μία μόνο γραμμή, ώστε το νέο διαμέρισμα να προσαρτάται αυτόματα κατά την εκκίνηση του λειτουργικού.

Σειρά έχει η τροποποίηση του αρχείου fstab στον κατάλογο /etc, το οποίο ανοίγουμε με δικαιώματα υπερχρήστη και με τη βοήθεια του nano. Θα προσθέσουμε στο αρχείο μία μόνο γραμμή, ώστε το νέο διαμέρισμα να προσαρτάται αυτόματα κατά την εκκίνηση του λειτουργικού.

Ιδού η γραμμή που εμείς προσθέσαμε στο /etc/fstab. Στη δική σας περίπτωση θα διαφέρει το UUID, ο κατάλογος προσάρτησης (/mnt/wdcBlue1TB) -- δεν αποκλείεται και το είδος του συστήματος αρχείων (ext4).

Ιδού η γραμμή που εμείς προσθέσαμε στο /etc/fstab. Στη δική σας περίπτωση θα διαφέρει το UUID, ο κατάλογος προσάρτησης (/mnt/wdcBlue1TB) — δεν αποκλείεται και το είδος του συστήματος αρχείων (ext4).

Αφού κάναμε την προσθήκη μας στο fstab, είναι ώρα να προσαρτήσουμε τη νέα κατάτμηση.

Αφού κάναμε την προσθήκη μας στο fstab, είναι ώρα να προσαρτήσουμε τη νέα κατάτμηση. Ξεκινάμε δημιουργώντας τον κατάλογο προσάρτησης (1) κι αμέσως μετά πραγματοποιούμε την ίδια την προσάρτηση (2). Θέλουμε να βεβαιωθούμε ότι όλα έχουν πάει καλά, γι’ αυτό και παρατηρούμε την έξοδο του df (3). Η τελευταία γραμμή μάς καθησυχάζει, μας χαροποιεί και μας γεμίζει αισιοδοξία για τη ζωή!

Το νέο διαμέρισμα που δημιουργήσαμε και προσαρτήσαμε είναι ορατό τόσο από από το guest OS (Ubuntu Server, αριστερά), όσο κι από το host OS (openSUSE, δεξιά). Καλό αυτό, ωστόσο όταν το VM είναι ενεργό σκοπεύουμε να γράφουμε και να διαβάζουμε δεδομένα μόνον από το guest OS.

Το νέο διαμέρισμα που δημιουργήσαμε και προσαρτήσαμε είναι ορατό τόσο από από το guest OS (Ubuntu Server, αριστερά), όσο κι από το host OS (openSUSE, δεξιά). Καλό αυτό, ωστόσο όταν το VM είναι ενεργό σκοπεύουμε να γράφουμε και να διαβάζουμε δεδομένα μόνον από το guest OS.

12 Responses to “Προσωπικό cloud με το openSUSE, μέρος 2”

  1. djmouzz | 03/01/2016 at 23:44

    Εξαιρετικό το άρθρο για μια ακόμη φορά φυσικά. Θα ήθελα να ρωτήσω τα εξής:
    1. Ποια είναι τα πλεονεκτήματα χρήσης του KVM έναντι του VirtualBox;
    2. Το KVM και το esxi είναι παρόμοιας λογικής;

    • subZraw | 05/01/2016 at 11:25

      Ωραίες ερωτήσεις :)

      Οι απαντήσεις προκύπτουν αφού ξεκαθαρίσουμε την έννοια του hypervisor ή αλλιώς virtual machine monitor (VMM), καθώς και τα δύο βασικά είδη hypervisors.

      Γενικά, λοιπόν, ο hypervisor είναι το λογισμικό για τη δημιουργία και τη διαχείριση εικονικών μηχανών. Ένας hypervisor ενδέχεται να υποβοηθείται από το firmware ή το hardware, αλλά αυτό δεν έχει σημασία για την κουβέντα μας.

      Υπάρχουν δύο βασικά είδη hypervisors.

      Type 1 (native ή bare metal). Τρέχουν απευθείας στο hardware του host computer. Κάθε guest operating system υπό την εποπτεία ενός bare metal hypervisor υφίσταται ως διεργασία (process). Παραδείγματα σύγχρονων bare metal hypervisors αποτελούν τα VMware ESXi και Microsoft Hyper-V.

      Type 2 (hosted). Τρέχουν *πάνω* από ένα άλλο OS, ως απλές εφαρμογές. Εκτός κάποιων εξαιρέσεων, τα guests των hosted hypervisors δεν βλέπουν το φυσικό hardware του host computer. Παραδείγματα σύγχρονων hosted hypervisors αποτελούν τα VMware Workstation/Fusion/Player και VirtualBox.

      Τώρα, το KVM του Linux, καθώς και το bhyve του FreeBSD, βρίσκονται κάπου ανάμεσα σ’ αυτές τις δύο κατηγορίες. Αμφότερα υφίστανται ως kernel modules κι όταν φορτώνονται προσδίδουν στο host OS χαρακτηριστικά Type 1 hypervisor. Όμως το Linux και το FreeBSD είναι λειτουργικά συστήματα γενικής χρήσης, επομένως εκτός από τα KVM ή τα bhyve VMs έχουμε κι άλλες εφαρμογές να διεκδικούν τους πόρους του host computer. Υπό αυτή την έννοια, τα KVM και bhyve δεν μπορούν να θεωρηθούν ως καθαρόαιμοι Type 1 hypervisors.

      Στην πράξη –και με δεδομένο το Linux ως host OS– ένα KVM VM είναι γρηγορότερο από ένα αντίστοιχο VMware ή VirtualBox VM (στο ίδιο host computer). Αν όμως μιλάμε για guest OS που προορίζεται για χρήση desktop (κι όχι server), τότε οι έξτρα drivers γραφικών που διατίθενται από τα VMware Workstation/Fusion/Server και VirtualBox δίνουν την αίσθηση ενός γρηγορότερου guest.

      Ελπίζω να έριξα λίγο φως :)

      • NickTh | 06/01/2016 at 22:08

        Καλησπέρα και καλή χρονιά (μιας και πρόκειται για το πρώτο μου ποστ).
        Όντως οι έξτρα drivers των vmware / virtualbox προσδίδουν ταχύτητα, δεν είναι απλά μια αίσθηση.
        Το αν κάποιος θα χρησιμοποιήσει κάποια υπηρεσία/λογισμικό τρίτου ή εκείνο που αναπτύσσεται μέσα στον πυρήνα (kvm) εξαρτάται από το τι ακριβώς θέλει, καθώς και τι hardware διαθέτει.
        Ναι, το hardware παίζει μεγάλη σημασία (τη δεδομένη στιγμή), καθώς αναπτύσσεται το λεγόμενο PCI Passthrough (ή αλλιώς GPU Passthrough) και όποιος/α καταφέρει κάτι τέτοιο πλέον δεν πιάνουν μια τα vmware / virtualbox μπροστά στο KVM.
        Δυστυχώς το δικό μου hardware δεν υποστηρίζει τεχνολογία VT-d οπότε δεν μπορώ να δοκιμάσω.
        Φανταστείτε μόνο ότι μπορεί κάποιος να κάνει passthrough την κάρτα γραφικών στον Guest. Ελπίζω στο μέλλον να αναπτυχθεί ο κώδικας εκείνος που χρειάζεται για να υποστηρίζονται και PCI χωρίς την προϋπόθεση του VT-d ή/και του FLReset, ή να έχω διαθέσιμα τα χρήματα για αγορά νέου Hardware :)

  2. djmouzz | 08/01/2016 at 11:35

    Πολύ ενδιαφέροντα όλα. Εμπειρία από KVM δεν έχω , στη δουλειά esxi χρησιμοποιούμε -τα πάει αρκετά καλά- αλλά η λύση KVM σε mid range μηχάνημα (core i3) είναι άκρως δελεαστική. Ένα μηχανηματάκι 2-3 κάρτες δικτύου κι ατελείωτα πειράματα. Η λειτουργία των KVM συστημάτων με χρήση συγκεκριμένης hardware κάρτας δικτύου είναι άκρως δελεαστική.

  3. vastsek | 04/02/2016 at 18:57

    Καλησπέρα, πολύ ωραίο το άρθρο.
    Είπα να δοκιμάσω να στήσω κι εγώ το δικό μου beast και θα θελα να ρωτήσω:
    Για να γίνει το bridge μήπως χρειάζονται να εγκατασταθουν επιπλέον πακέτα ή να δημιουργηθεί νέο Virtual Network από τον virtual manager;
    Δεν έχω την επιλογή που αναφέρεται στο Network Selection.
    Στόχος μου είναι να κάνω bridge την wlan0(host) με το eth0(guest)!

    • subZraw | 04/02/2016 at 19:06

      Καλησπέρα,
      Όπως φαίνεται κι από τα screenshots του άρθρου, αν μέσα από το YaST πας στο Install Hypervisor and Tools και προχωρήσεις στην εγκατάσταση τότε θα εγκατασταθούν *και* τα bridge utilities. Παρεμπιπτόντως, το bridging για τα VMs θα το κανονίσει αυτόματα το YaST!

      • vastsek | 04/02/2016 at 19:35

        Και εγώ κάπως έτσι το περίμενα, αλλά ευτυχώς ή δυστυχώς δεν έγινε! Θέλω να πιστεύω ότι τα bridge utilities είναι εγκατεστημενα και είναι θεμα ρύθμισης.
        Ας προσπαθησουμε και manual! :) Ευχαριστω.

  4. ToPnt | 01/11/2017 at 23:07

    Ωραία σειρά άρθρων..! Από το πρώτο άρθρο, μέχρι αυτό και ακόμη και τα υπόλοιπα που ακολουθούν!
    Σαν λάτρεις και του τερματικού, τα άλλα μπορεί να μου φανούν ακόμη πιο ενδιαφέρων ή ακόμη και οι περαιτέρω υλοποιήσεις που αναφέρεις βασιζόμενος σε αυτή την υποδομή έχουν τρομερό ενδιαφέρον. Όπως και πόσες πολλές προοπτικές προκύπτουν….. ;)

    Μόνο που έχω την εντύπωση πως σιγά σιγά θα πρέπει να εμπλακούν στο παιχνίδι και τα «Linux Container».. ώστε να καλυφθεί ίσος όσο το δυνατόν καλύτερα το θέμα των εικονικών τεχνολογιών που υπάρχουν. Και όχι για τίποτε άλλο, αλλά γιατί νομίζω πως και εσείς έχετε το μικρόβιο να ασχολείσθε με διάφορα… ;)

    Συγχαρητήρια. Καλή συνέχεια! :)

    • subZraw | 01/11/2017 at 23:24

      Χαιρόμαστε που βρίσκεις ενδιαφέροντα τα σχετικά άρθρα.

      ΥΓ. Σιγά μη μας τη γλιτώσουν τα containers ;)

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

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