SC VMM 2008 crashes with Linux IC v3.1
Σήμερα είχα ραντεβού σε ένα πελάτη σχετικά με την παραμετροποίηση ενός SCOM 2007R2. Κατά την είσοδό μου στο γραφείο της μηχανογράφησης, βλέπω έναν (σχεδόν) πανικόβλητο SysAdmin να παλέβει με έναν System Center Virtual Machine Manager 2008R2 SP1 στα πρόθυρα κατάρευσης!
Η εικόνα τραγική, Hosts not responding, VM’s in failed state, και από κάτω το Hyper-V Cluster καθώς και όλα τα VM Cluster Resources να χαίρουν άκρας υγείας!
Στα System Logs βλέπουμε το VMM Service να σκάει και να κάνει restart κάθε λίγα λεπτά. Λόγω των αλεπάλληλων restart, tasks όπως provisionning, live migration μένουμε ‘μισά’ για τον VMM με αποτέλεσμα να εμφανίζουν failed state VM’s (εξ ου και τα κοκκινάδια στην κονσόλα του VMM)
Καθώς λοιπόν το ψάχνουμε, βρίσκουμε στα event του VMM (Event Viewer –> Application and Services Log –> Microsoft –> VM Manager) τα Errors με Event Id 1 & 19999, και μαζί τις ‘μαγικές’ φράσεις :
System.ArgumentException: Version string portion was too short or too long
Microsoft.Carmine.ViridianImplementation.VirVMIntegrationService.PopulateKVPElements()
Όπου αρχίζω να υποψιάζομαι κάτι που τρέχει Integration Services με ‘παράξενο’ τρόπο …
Με βάση το event, καταλήγουμε στο ΚΒ 2586286 το οποίο αναφέρεται σε πρόβλημα το με το οποίο ο Virtual Machine Manager (2008, 2008R2, 2008R2 SP1) παθαίνει ταράκουλο, όταν τρέξει VM Refresh σε ένα Virtual Machine, το οποίο τρέχει Reh Had Enterprise Linux 6.0 or 6.1 καθώς και CentOS 6.0 με εγκατεστημένα Linux Integration Services version 3.1
Συγκεκριμένα, η έκδοση του Kernel που επιστρέφεται από το KVP (Key Value Pair) Exchange είναι μεγαλύτερη από όσο προβλέπεται (error 1 παραπάνω) και αυτό προκαλεί unhandled exception crash στον VMM!
Για την επίλυση του προβλήματος, απενεργοποιούμε το KVP Exchange, κάνοντας login ως root στο Linux VM και τρέχοντας την παρακάτω εντολή :
/sbin/chkconfig --level 35 hv_kvp_daemon off
Κατόπιν, κάνουμε kill το σχετικό process (ή απλά κάνουμε restart αν δεν ξέρουμε πώς)
Πίσω στην τρέλα του προβλήματος, ψάχνουμε το προβληματικό cluster και δεν βρίσκουμε κανένα Linux VM που να τρέχει integration services! Ψάχνοντας καλύτερα, βρήκαμε το VM σε έναν standalone staging / test server που ήταν VMM managed και του οποίου το VM είχε προκαλέσει όλη αυτή την αναταραχή στο VMM και την υποδομή του πελάτη …
(Φυσικά, η προγραμματισμένη δουλειά δεν έγινε [H])
Συμπέρασμα 1 : Τα φαινόμενα απατούν (άλλα έλεγε ο VMM άλλα το Cluster Service)
Συμπέρασμα 2 : Όταν ένα σύστημα έχει πολλά εργαλεία για την ίδια δουλειά, just stick with one (όλες οι παρενέργειες, πέρα από το vmm service restart, προκλήθηκαν από ενέργειες που έμειναν στη μέση στο VMM, και τις προχώρησε ο admin από το Cluster Manager ή το Hyper-V manager)
Συμπέρασμα 3 : Ένας κακός πιγκουίνος, φτάνει να σκοτώσει το θεμελιώδη λίθο του MS Private Cloud [6]
4 Comments
Recommended Comments