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

Ανάπτυξη VM και guest OS, από τη γραμμή εντολών

Αναλυτικά και βήμα προς βήμα δείχνουμε πώς δημιουργούμε εικονικές μηχανές QEMU/KVM και κατόπιν πώς τους εγκαθιστούμε το νέο openSUSE Leap 42.3, χωρίς να εγκαταλείψουμε το τερματικό ούτε για μια στιγμή.

Θα δούμε σε πολύ λίγο πώς φτιάχνουμε ένα πλήρες VM με το λειτουργικό του ξεκινώντας από το μηδέν και δουλεύοντας αποκλειστικά από τη γραμμή εντολών. Το αληθινό μας κίνητρο δεν πηγάζει από μια κάποια επιθυμία για έξυπνη ή έστω πρωτότυπη ανάπτυξη εικονικών μηχανών. Πολύ περισσότερο, αυτό που θέλουμε είναι να δημιουργήσουμε κάτι σαν template VM κι από εκεί πολύ γρήγορα να συγκροτήσουμε ένα ολόκληρο cluster. Το γιατί θα σχεδίαζε κάποιος κάτι παρόμοιο, καθώς και το πώς θα εργαζόταν για να υλοποιήσει το σχέδιό του, αποτελεί θέμα επόμενου άρθρου. Προς το παρόν δουλεύουμε σε ένα PC με openSUSE Leap, στο οποίο προϋπάρχει ήδη η απαραίτητη υποδομή λογισμικού για τη δημιουργία και τη διαχείριση εικονικών μηχανών QEMU/KVM. Σε περίπτωση που δεν έχετε ασχοληθεί ξανά με το θέμα, προτείνουμε να διαβάσετε τη σχετική σειρά άρθρων.

Το νέο μας VM θα έχει έναν εικονικό δίσκο μεγέθους 128GiB, στον οποίο θα εγκατασταθεί το λειτουργικό του σύστημα. Ο δίσκος αυτός στην πραγματικότητα θα είναι ένα sparse file τύπου QCOW2, αποθηκευμένο σε συγκεκριμένο κατάλογο του host OS. Για να χρησιμοποιήσουμε και την επίσημη ορολογία στον κόσμο του libvirt, ο δίσκος του VM δεν είναι παρά ένα volume εντός ενός συγκεκριμένου pool (σκεφτείτε: volume = αρχείο και pool = κατάλογος).

Δημιουργία νέου storage pool

Για λόγους καλής διαχείρισης, ας μη χρησιμοποιήσουμε κάποιο από τα υπάρχοντα pools. Αντίθετα, ας επιστρατεύσουμε το εργαλείο virsh ώστε να φτιάξουμε ένα νέο. Πρώτα όμως χρειαζόμαστε έναν κατάλογο, ο οποίος θα αποτελέσει το νέο μας pool. Από ένα τερματικό πληκτρολογούμε:

userson at siglufjörður ~> mkdir /mnt/keflavik/pools/delta

Σημείωση. Δεν εργαζόμαστε από το λογαριασμό του root αλλά ο χρήστης μας, με username το userson, ανήκει στο group ονόματι libvirt. Εννοείται εξάλλου ότι ο ίδιος χρήστης έχει και δικαίωμα εγγραφής εντός του καταλόγου /mnt/keflavik/pools. Να υπογραμμίσουμε τέλος ότι στη μεταβλητή περιβάλλοντος LIBVIRT_DEFAULT_URI έχει τεθεί η τιμή qemu:///system. Συγκεκριμένα, στο αρχείο ~/.bashrc του userson υπάρχει αυτή η γραμμή: export LIBVIRT_DEFAULT_URI=qemu:///system.

Το ίδιο το pool το ορίζουμε πληκτρολογώντας virsh pool-define-as delta dir - - - - /mnt/keflavik/pools/delta (ναι, οι τέσσερις παύλες χρειάζονται). Δείτε όλα τα pools που έχουμε στο σύστημά μας:

userson at siglufjörður ~> virsh pool-list --all
Name                 State      Autostart
-------------------------------------------
default              active     yes       
delta                inactive   no        
ISOs                 active     yes       
localVMs             active     yes

Παρατηρήστε ότι στο εργαλείο virsh δώσαμε την εντολή pool-list και σ’ αυτή περάσαμε την παράμετρο --all, ώστε στην έξοδο να συμπεριληφθούν τόσο τα ενεργά (active) όσο και τ’ ανενεργά (inactive) pools. Το delta που μόλις ορίσαμε είναι ανενεργό — κι αυτό καθόλου δεν πρέπει να μας εκπλήσσει. Προκειμένου να το ενεργοποιήσουμε πληκτρολογούμε virsh pool-start delta. Επαληθεύουμε ότι το νέο pool έχει πράγματι ενεργοποιηθεί ζητώντας τη λίστα με όλα τα pools του συστήματος — αλλά αυτή τη φορά χωρίς να δώσουμε την παράμετρο --all:

userson at siglufjörður ~> virsh pool-list
Name                 State      Autostart
-------------------------------------------
default              active     yes       
delta                active     no        
ISOs                 active     yes       
localVMs             active     yes

Τέλεια όλα εκτός από αυτό το Autostart, το οποίο για το delta είναι no ενώ για όλα τα άλλα pools είναι yes. Αυτό σημαίνει ότι το delta δεν θα ενεργοποιείται αυτόματα κατά την εκκίνηση του host OS. Υποθέτουμε ότι θα θέλετε να ενεργοποιείται αυτόματα, οπότε δώστε virsh pool-autostart delta και βεβαίως επαληθεύστε:

userson at siglufjörður ~> virsh pool-list
Name                 State      Autostart
-------------------------------------------
default              active     yes       
delta                active     yes
ISOs                 active     yes       
localVMs             active     yes

Θέλετε μήπως περισσότερες πληροφορίες για το νέο pool; Αν ναι, απλά γράψτε:

userson at siglufjörður ~> virsh pool-info delta
Name:           delta
UUID:           60c43540-25eb-4898-858a-0a54476e3328
State:          running
Persistent:     yes
Autostart:      yes
Capacity:       2.00 TiB
Allocation:     32.20 MiB
Available:      2.00 TiB

Δημιουργία νέου volume

Τώρα που έχουμε το νέο μας pool, το delta, ας φτιάξουμε μέσα σε αυτό ένα volume. Θα το ονομάσουμε leapzero.qcow2 και θα αποτελέσει τον εικονικό δίσκο, μεγέθους 128GiB, της μηχανής που πρόκειται να υλοποιήσουμε σε λίγο. Στο τερματικό μας γράφουμε: virsh vol-create-as delta --name leapzero.qcow2 --capacity 128G --format qcow2. Πώς βλέπουμε όλα τα volumes ενός pool; Έτσι:

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

Ιδού και περισσότερες πληροφορίες για το νέο volume:

userson at siglufjörður ~> virsh vol-info leapzero.qcow2 delta
Name:           leapzero.qcow2
Type:           file
Capacity:       128.00 GiB
Allocation:     196.00 KiB

Παρατηρήστε ότι ενώ το αρχείο εμφανίζεται να έχει μέγεθος 128GiB, στην πραγματικότητα καταλαμβάνει μόλις 196KiB! Πάρα πολύ ωραία, έχουμε ένα ωραιότατο sparse file και είμαστε πλέον σε θέση να υλοποιήσουμε το VM μας.

Αυτόματη κατασκευή VM

Κατ’ αρχάς κατεβάστε, αν δεν το έχετε ήδη κατεβάσει, το ISO image του openSUSE Leap 42.3: αυτό θα είναι το guest OS του VM που πρόκειται να δημιουργήσουμε. Το αρχείο που θα πάρετε βάλτε το στο pool όπου οργανώνετε τα ISO images. Αμέσως μετά τη μεταφορά μην ξεχάσετε να φρεσκάρετε τα περιεχόμενα του pool, π.χ., πληκτρολογώντας κάτι σαν virsh pool-refresh ISOs.

Κάθε εικονική μηχανή QEMU/KVM ορίζεται από ένα αρχείο XML, στο οποίο περιγράφονται τα χαρακτηριστικά του VM. Εμείς τώρα θέλουμε να δημιουργήσουμε ένα νέο VM για το openSUSE, οπότε το πρώτο πράγμα που χρειαζόμαστε είναι αυτό το αρχείο XML. Πληκτρολογήστε:

userson at siglufjörður ~> virt-install \
> --name leapzero --os-variant opensuse42.3 \
> --memory 2048 --cpu host-model-only --vcpus=2 \
> --network bridge=br0,model=virtio \
> --disk /mnt/keflavik/pools/delta/leapzero.qcow2,bus=virtio \
> --cdrom /mnt/keflavik/pools/ISOs/openSUSE-Leap-42.3-DVD-x86_64.iso \
> --print-xml 1 > leapzero.xml

(Τα σύμβολα > στα αριστερά δεν τα πληκτρολογούμε εμείς. Τα εμφανίζει το BASH λόγω του \ στα δεξιά της προηγούμενης γραμμής κι εξαιτίας του [Enter] που πατάμε.) Παίρνουμε έτσι ένα αρχείο XML, το leapzero.xml, το οποίο περιγράφει μια εικονική μηχανή με 2GiB RAM, δύο επεξεργαστές κι έναν δίσκο. Στη ίδια μηχανή υπάρχει κι ένα εικονικό CDROM drive, στο οποίο είναι προσαρτημένο το ISO για την εγκατάσταση του openSUSE Leap 42.3.

Το full path προς ένα οποιοδήποτε volume. Σίγουρα θα παρατηρήσατε ότι στην προηγούμενη εντολή δώσαμε το full path προς το QCOW2 image που αντιστοιχεί στο δίσκο της μηχανής, καθώς και το πλήρες path προς το ISO image του μέσου εγκατάστασης. Δεν δώσαμε, μ’ άλλα λόγια, τα ονόματα των volumes, ούτε των αντίστοιχων pools. Ίσως θέλετε έναν κάπως αυτοματοποιημένο τρόπο, ώστε με δεδομένα τα ονόματα volume και pool να παίρνετε το full path προς το αρχείο που αντιστοιχεί στο volume. Μια τέτοια μέθοδος θα αποδεικνυόταν χρήσιμη αν, π.χ., σχεδιάζετε ν’ αναπτύξετε κάποια scripts, στο πλαίσιο ενός μεγαλύτερου project. Ιδού ένας τρόπος, ο οποίος δεν είναι ούτε ο μοναδικός ούτε ο καλύτερος: virsh vol-dumpxml --vol leapzero.qcow2 delta | grep path | awk -F "<path>" '{ print $2 }' | awk -F "</path>" '{ print $1 }' (φυσικά, στην περίπτωσή σας αλλάζουν τα ονόματα των volume και pool). Δοκιμάστε τον.

Sound device για το VM; Με την προηγούμενη εντολή, στο XML της μηχανής περιλαμβάνεται και ορισμός για υποσύστημα ήχου. Αν προορίζετε το VM σας για χρήση server, τότε μάλλον δεν χρειαζόσαστε το αντίστοιχο device. Προκειμένου να το αφαιρέσετε ανοίξτε το αρχείο leapzero.xml με έναν text editor και διαγράψτε τη γραμμή <sound model="ich6"/> (βρείτε τη κοντά στο τέλος του XML).

Πριν συνεχίσουμε ανοίγουμε το αρχείο leapzero.xml μ’ έναν text editor και ψάχνουμε γι’ αυτό το string: <on_reboot>destroy</on_reboot>. Αλλάζουμε το destroy σε restart. Το νέο string, δηλαδή, θα είναι αυτό: <on_reboot>restart</on_reboot>. Αποθηκεύουμε την αλλαγή, βγαίνουμε από τον editor και είμαστε πλέον βέβαιοι ότι το VM θα συμπεριφέρεται φυσιολογικά κατά την επανεκκίνησή του.

Χωρίς την αλλαγή που επιδεικνύουμε, κάθε φορά που επανεκκινούμε το VM αυτό απλά θα κλείνει.

Χωρίς την αλλαγή που επιδεικνύουμε, κάθε φορά που επανεκκινούμε το VM αυτό απλά θα κλείνει.

Θαυμάσια. Έχουμε το ωραιότατο XML της μηχανής όπως ακριβώς το θέλουμε, αλλά όχι την ίδια τη μηχανή. Προκειμένου να την ορίσουμε με βάση το XML, αρκεί να πληκτρολογήσουμε virsh define leapzero.xml --validate. Η δημιουργία (ορισμός) του VM πραγματοποιείται ακαριαία. Πλέον, δίνοντας virsh list --all, μεταξύ των άλλων VMs βλέπουμε κι ένα με όνομα leapzero. Η μηχανή συμπεριλαμβάνεται και στη σχετική λίστα του Virtual Machine Manager (δώστε virt-manager για να τον ξεκινήσετε).

Το νέο VM δεν έχει ακόμα guest OS. Η εγκατάστασή του γίνεται ξεκινώντας τον εικονικό υπολογιστή, π.χ., με ένα virsh start leapzero. Για τη συνέχεια βέβαια θα χρειαστούμε πρόσβαση στην οθόνη (κονσόλα) του. Αφήστε για λίγο το τερματικό και στραφείτε στον Virtual Machine Manager (από το περιβάλλον του, επιλέξτε το VM και κάντε κλικ στο κουμπί [Open]). Μετά την εγκατάσταση του guest OS (δηλαδή του openSUSE Leap 42.3, στο πλαίσιο της παρουσίασής μας) θα μπορέσετε και πάλι να επιστρέψετε στο τερματικό σας.

Αυτόματη εγκατάσταση guest OS με το AutoYaST

Από τη στιγμή που το guest OS για το νέο VM είναι το openSUSE, η ίδια η εγκατάσταση του λειτουργικού συστήματος είναι εύκολο να αυτοματοποιηθεί με τη βοήθεια του AutoYaST. Το leap423-autoinst.xml είναι ένα AutoYaST profile για την εγκατάσταση του Leap 42.3 σε ρόλο server (δεν υπάρχει περιβάλλον γραφικών), στο VM που μόλις φτιάξαμε (κι όχι μόνο). Μπορείτε να κατεβάσετε το προαναφερθέν XML από το https://github.com/colder-is-better/autoyast.

Χρήση του συστήματος AutoYaST για την αυτόματη εγκατάσταση του openSUSE Leap 42.3. Διαβάστε το σχετικό άρθρο στο τεύχος 059 για περισσότερες λεπτομέρειες.

Χρήση του συστήματος AutoYaST για την αυτόματη εγκατάσταση του openSUSE Leap 42.3. Διαβάστε το σχετικό άρθρο στο τεύχος 059 για περισσότερες λεπτομέρειες.

Μετά το πέρας της 100% αυτοματοποιημένης διαδικασίας εγκατάστασης, στο λειτουργικό της μηχανής θα υπάρχει ένας λογαριασμός χρήστη ονόματι User Userson, με username το userson και password το topsecret. Ο δίσκος του VM, μεγέθους 128GiB, θα έχει δύο κατατμήσεις: μία μεγέθους 2GiB, για χρήση swap, καθώς κι άλλη μία μεγέθους 126GiB, η οποία αποτελεί το root filesystem. Η δεύτερη αυτή κατάτμηση είναι διαμορφωμένη κατά Ext4.

Προετοιμασία template VM

Τώρα που έχουμε το ωραιότατο QEMU/KVM VM με το openSUSE Leap 42.3 εγκατεστημένο, μια καλή ιδέα είναι να το χρησιμοποιούμε ως πρότυπο (template) για τη δημιουργία άλλων VMs. Η βασική ιδέα είναι ότι κλωνοποιούμε το υπάρχον VM όσες φορές θέλουμε κι έτσι δημιουργούμε πολύ γρήγορα νέα VMs. Κάθε νέο VM αρχικά έχει τα χαρακτηριστικά του προτύπου, δηλαδή δίσκο ιδίου μεγέθους, 2GiB μνήμης RAM, μία κάρτα ethernet κ.ο.κ. Από εκεί και πέρα είναι πολύ εύκολο να προσθέτουμε δίσκους, κάρτες δικτύου, ήχου κ.λπ. ή να μεταβάλλουμε την ποσότητα της μνήμης ενός οποιουδήποτε VM. Εργασίες σαν αυτές πραγματοποιούνται με τη βοήθεια του εργαλείου virsh και σε άλλα άρθρα θα έχουμε την ευκαιρία να δούμε συγκεκριμένα παραδείγματα. Προς το παρόν, ας προετοιμάσουμε το leapzero ώστε να του ταιριάζει καλύτερα ο ρόλος του template VM.

Αφαίρεση συσκευής CD/DVD. Από τη στιγμή που έχουμε τελειώσει με την εγκατάσταση του guest OS, το VM δεν χρειάζεται άλλο τη συσκευή CD/DVD. Αν λοιπόν η μηχανή είναι ενεργή την κλείνουμε, πληκτρολογώντας virsh shutdown leapzero. Ακολούθως ζητάμε τη λίστα με τα block devices του VM:

userson at siglufjörður ~> virsh domblklist leapzero
Target     Source
------------------------------------------------
vda        /mnt/keflavik/pools/delta/leapzero.qcow2
hda        /mnt/keflavik/pools/ISOs/openSUSE-Leap-42.3-DVD-x86_64.iso

Ωραία. Το device που δεν χρειαζόμαστε είναι το hda, οπότε το αφαιρούμε αμέσως:

userson at siglufjörður ~> virsh detach-disk leapzero hda --persistent

Επαληθεύουμε ότι πράγματι αφαιρέθηκε:

userson at siglufjörður ~> virsh domblklist leapzero
Target     Source
------------------------------------------------
vda        /mnt/keflavik/pools/delta/leapzero.qcow2

Για τη συνέχεια θέλουμε το VΜ και πάλι ενεργό, οπότε το ξεκινάμε γράφοντας virsh start leapzero.

SSH passwordless logins. Το VM είναι για προσωπική χρήση — και πιθανώς το ίδιο θα αληθεύει και για κάθε κλώνο του. Προαιρετικά, λοιπόν, μπορούμε να τοποθετήσουμε το δημόσιο κλειδί του χρήστη μας από τον physical host, στο λογαριασμό ενός χρήστη (π.χ., του userson) στο template VM. Κατ’ αυτόν τον τρόπο θα συνδεόμαστε στον αντίστοιχο λογαριασμό του VM μέσω SSH και χωρίς να πληκτρολογούμε password. Η τοποθέτηση του δημοσίου κλειδιού επιτυγχάνεται γράφοντας κάτι σαν ssh-copy-id userson@leapzero.colder.is, όπου στη θέση του leapzero.colder.is θα βάλετε το FQDN (Fully Qualified Domain Name) ή απλά την αριθμητική διεύθυνση IP του δικού σας VM.

Απλός χρήστης με δικαιώματα passwordless sudo. Αν εγκαταστήσατε το Leap 42.3 χρησιμοποιώντας το AutoYaST profile που σας προτείναμε, τώρα έχετε έναν χρήστη, με username το userson, ο οποίος για τις όποιες εργασίες διαχείρισης συστήματος μπορεί και καταφεύγει στο sudo. Το password του userson είναι ίδιο με το password του root — και συγκεκριμένα είναι το topsecret. Ίσως θελήσετε να το αλλάξετε, ειδικά αν σε υπηρεσίες του VM έχουν (απομακρυσμένη) πρόσβαση κι άλλα πρόσωπα. Κάτι άλλο που ίσως αξίζει να δείτε, είναι να επιτρέψετε στον userson να χρησιμοποιεί το sudo χωρίς καν να πληκτρολογεί password.

Περιποίηση των repositories. Μετά την εγκατάσταση του λειτουργικού, συνδεθείτε στο VM και πληκτρολογήστε zypper lr. Θα δείτε τη λίστα με τα repositories (αποθετήρια) που γνωρίζει ή/και χρησιμοποιεί το λειτουργικό. Ίσως ορισμένα εξ αυτών είναι απενεργοποιημένα, π.χ., επειδή κάποιο repository προέρχεται από το DVD της εγκατάστασης. Άλλα repositories, εξάλλου, ενδεχομένως να έχουν παράξενα aliases ή/και names. Καλό θα ήταν να αφαιρέσετε τα απενεργοποιημένα repositories καθώς και να μετονομάσετε κάποια, αν μη τι άλλο ώστε με μια ματιά να καταλαβαίνετε αμέσως ποιο είναι ποιο. Για τη διαγραφή ενός απενεργοποιημένου repository πληκτρολογήστε κάτι σαν sudo zypper rr repo_number, όπου το repo_number είναι ο αριθμός του repository όπως εμφανίζεται στην πρώτη από αριστερά στήλη, στην έξοδο της εντολής zypper lr. Τώρα, για αλλαγές στα ονόματα ή/και στα aliases των αποθετηρίων, δώστε πρώτα zypper lr -u. Χάρη την παράμετρο -u παίρνουμε μια νέα στήλη, με τα URI (Uniform Resource Identifier) των repositories. Παρατηρώντας ένα URI κι ανεξάρτητα από τα ονόματα ή τα aliases, είναι εύκολο να συμπεράνουμε, π.χ., αν το τάδε αποθετήριο περιλαμβάνει τα πακέτα OSS, αν το δείνα αποθετήριο έχει τα updates για τα πακέτα που δεν είναι OSS κ.ο.κ. Έτσι, έχουμε όλες τις πληροφορίες προκειμένου οι όποιες αλλαγές σε aliases ή/και σε ονόματα να έχουν νόημα. Για να αλλάξουμε το όνομα του repository υπ’ αριθμόν p γράφουμε κάτι σαν sudo zypper mr -n new_name p, όπου το new_name είναι το νέο όνομα. Για να αλλάξουμε το alias του repository υπ’ αριθμόν q πληκτρολογούμε κάτι σαν sudo zypper nr q new_alias, όπου το new_alias είναι το νέο συνώνυμο.

Περιποίηση της λίστας με τα αποθετήρια λογισμικού. Πρώτα φροντίζουμε για τα ονόματα (1), μετά για τα συνώνυμα (2). Σημείωση: Οι επεμβάσεις καλλωπισμού λαμβάνουν χώρα στο workspace υπ' αριθμόν 3. Ευχαριστούμε.

Περιποίηση της λίστας με τα αποθετήρια λογισμικού. Πρώτα φροντίζουμε για τα ονόματα (1), μετά για τα συνώνυμα (2). Σημείωση: Οι επεμβάσεις καλλωπισμού λαμβάνουν χώρα στο workspace υπ’ αριθμόν 3. Ευχαριστούμε.

Φορητή δικτύωση. Πλέον, το VM που έχουμε είναι κατάλληλο να χρησιμοποιηθεί ως πρότυπο, για την ταχύτατη ανάπτυξη άλλων μηχανών. Αξίζει μόνο να βεβαιωθούμε για δυο-τρεις ρυθμίσεις σχετικές με τη δικτύωση. Συνδεόμαστε στο VM μέσω SSH και πληκτρολογούμε sudo yast2 lan. Δείτε τα δύο screenshots που ακολουθούν, διαβάστε και τις αντίστοιχες περιγραφές.

Διαχείριση δικτύωσης από την υπηρεσία Wicked και υποστήριξη του IPv6.

Στην εικονική μας μηχανή δεν θέλουμε τον Network Manager να χειρίζεται θέματα δικτύωσης –δεν έχει πολύ νόημα για VMs με ένα WAN interface, χώρια που μας κρύβει ορισμένες παραμέτρους–, γι’ αυτό κι έχουμε επιλεγμένη την υπηρεσία Wicked (1). Το IPv6 εξάλλου είναι ενεργοποιημένο, αφού πλέον δεν είναι καθόλου σπάνιο να υποστηρίζεται από –εικονικούς ή φυσικούς– routers (2). Στα δικά μας εικονικά δίκτυα, τέλος, η απόδοση διευθύνσεων IP και hostnames γίνεται κεντρικά, από τον DHCP server και με βάση τα MAC addresses των client VMs. Γι’ αυτό και στο συγκεκριμένο template VM δεν έχουμε αναθέσει τιμή στο DHCP Client Identifier, ενώ για το Hostname to Send έχει τεθεί το AUTO (3).

Αποδοχή του hostname που προτείνει ο DHCP server του τοπικού δικτύου.

Το hostname του VM είναι leapzero (1), οποιοδήποτε όνομα όμως προτείνει ο DHCP server γίνεται αποδεκτό (2). Το domain name, εξάλλου, το αφήνουμε κενό, αφού και πάλι θα δεχτούμε το domain name που υπαγορεύει ο DHCP (3).

Σε επόμενα άρθρα θα δούμε τι εννοούμε με την κλωνοποίηση VMs. Μέσα από συγκεκριμένα παραδείγματα θα ξεκινήσουμε από το template VM που μόλις φτιάξαμε και θα αναπτύξουμε πιο εξειδικευμένες μηχανές — έως και ολόκληρα clusters από εικονικές μηχανές.

2 Responses to “Ανάπτυξη VM και guest OS, από τη γραμμή εντολών”

  1. blackpit | 18/08/2017 at 23:38

    Πολύ καλό και αναλυτικό το άρθρο. Επίσης, νομίζω πως έφτασε ο καιρός να δοκιμάσω το OpenSuse σε κάποιο VM, το βλέπω αρκετά προσεγμένη διανομή από τα διάφορα tutorials.

    Μια ερώτηση. Χρησιμοποιείτε κάποιο script για να σβήσετε αρχεία που δε πρέπει να υπάρχουν στο template, όπως π.χ. history στο .bashrc (αν χρησιμοποιείτε το bash ως shell), τα ssh host keys ή να καθαρίσετε το /var/log, ή κάποιο άλλο εργαλείο τύπου virt-sysprep, πριν μετατρέψετε το VM σε template? Όταν έφτιαχνα κάποια VM ώστε να τα κάνω templates, έκανα μια υποτυπώδη διαδικασία καθαρισμού αλλά ίσως χρησιμοποιείτε κάποια καλύτερη μέθοδο για reset του VM.

    Φιλικά,
    Πάνος

    • subZraw | 18/08/2017 at 23:51

      Καλησπέρα Πάνο,
      Η αλήθεια είναι ότι δεν ενδιαφερόμαστε τόσο για τον “καθαρισμό” των templates, αφού τα χρησιμοποιούμε κυρίως σε προσωπικά projects και δεν τα μοιράζουμε. Ίσως όμως θα άξιζε να αναπτύξουμε ένα ξεχωριστό άρθρο, αφού πρώτα διερευνήσουμε τι έχει νόημα να καθαριστεί και τι όχι.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

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