XenServer – VDI is not available

VDI is not available

Ein immer wieder auftretendes und nerviges Problem auf XenServern ist die Meldung “Error: Starting VM – The VDI is not available”, wenn man versucht eine VM zu starten und der Start nach kurzer Zeit fehlschlägt.
Meist tritt dieses Problem auf, wenn es vorher Probleme mit der Konsolidierung von Snapshots gab oder eine VM hart per “destroy domain” beendet werden musste.

Hintergrund ist der, dass der XenServer das VDI (virtual disk image) noch in Benutzung sieht und so der startenden VM den Zugriff verwehrt.

Befindet sich die VM in einem Pool kann als schneller Workaround versucht werden per “Start on Server” die VM wieder genau auf dem XenServer zu starten, auf dem sie vorher lief. Das funktioniert in vielen Fällen, birgt aber das Risiko, dass das Grundproblem nicht behoben ist und sich die VM nicht mehr per XenMotion verschieben läßt. Versucht man dieses trotzdem, weil man z.B. das eigentliche Problem zwischenzeitlich wieder vergessen hat, schmiert die VM mit Sicherheit wieder ab.

Zur Lösung des Problems finden sich im Netz einige Ansätze, aus denen ich meine beiden Favoriten vorstellen möchte.

Variante 1:

Hilft ohne tiefere Kenntnisse des XenServers, geht rein mit der GUI, dauert aber je nach Pool-Größe länger und funktioniert nur bei hinreichenden Reserven im Pool.

In 95% der Fälle hilft ein reboot aller XenServer des Pools, möglichst angefangen mit dem Pool-Master.
Die betroffene VM muss die ganze Zeit ausgeschaltet sein, während alle anderen VMs per XenMotion auf die jeweils noch aktiven XenServer verschoben werden. So können alle XenServer-Hosts rebootet werden während die VMs weiterlaufen.
Bei Einzelservern hilft entsprechend der Reboot des Hosts, nur müssen hier mangels weiterer XenServer die VMs alle beendet werden.

Größter Nachteil dieser Variante ist in der Regel die doch recht lange Zeit, die es dauert die ganzen VMs zwischen den XenSevern zu migrieren bis jeder einmal leer war und rebootet werden konnte. Und da in dieser Zeit die betroffene VM ausgeschaltet bleiben muss, bleibt diese Option eher nur für unkritische VMs oder Nutzer die auf die GUI beschränkt sind.

Variante 2:

Verlangt die Nutzung des CLI und auch erhöhte Aufmerksamkeit, löst dafür das Problem aber recht schnell und ohne reboot der XenServer. Ebenso in den wenigen Fällen, in denen die reboots nicht geholfen haben.

Als erstes müssen wir zuverlässig(!) den Staus der betroffenen VM ermitteln, da diese definitiv ausgeschaltet sein muss. Da wir hier der GUI nicht zu 100% vertrauen können, öffnen wir die Konsole des XenServers auf dem die VM zuletzt lief und lassen uns alle laufenden VMs mit list_domains anzeigen. Das Ergebnis sieht dann wie folgt aus:

[root@ii-rx3-xen2 ~]# list_domains
id | uuid | state
0 | 99d843bc-56fd-438d-a7e2-f9d4a2e376a3 | R
3 | bf08ad3b-090a-f2fb-316f-52a8fde03ea0 | RH
4 | 788a8e35-1412-cd75-3e76-fdd54d7bc2d2 | B
6 | d80c320b-acdc-fcaa-e310-ffaa8a035577 | B H
7 | fc3cf0d9-bd27-bee2-9f9a-e254875d7cdc | B H
9 | 1059c5bc-f0cf-6037-7a3c-0e399a492e1d | B H
10 | 4c976399-92e8-a693-edd6-1191c77a1fba | B H
11 | ac12739c-3cdc-046d-6fdf-678c9abb1dfc | B H
12 | 77acf837-0b1b-1454-f77b-940a7b501c4d | B H
14 | 7297e428-2f92-a9f0-5ad1-9fea46856c3d | RH
15 | 3fe9ff84-d1bb-44d5-b29d-55f94a8c5013 | RH
16 | b7998ced-0ea1-5772-2260-5f3f5a39e36d | B H

Die UUID unserer VM ermittelt man am schnellsten unter “General” in der GUI, dort ist der unterste Eintrag die UUID der VM.

Wer nicht die ganze Liste abgleichen möchte, kürzt das Ganze ein wenig ab und ergänzt den Befehl um die UUID (list_domains | <UUID>), dann wird nur noch die gesuchte VM ausgegeben.

[root@ii-rx3-xen2 ~]# list_domains | grep 77acf837-0b1b-1454-f77b-940a7b501c4d
12 | 77acf837-0b1b-1454-f77b-940a7b501c4d |    B H

In unserem Falle läuft die gesuchte VM noch, wenn Sie nicht mehr läuft kommt einfach ein leerer Prompt:

[root@iirxp4xen1 ~]# list_domains | grep 2893fe8f-30df-42bb-9f43-896089d531d5
[root@iirxp4xen1 ~]#

Wenn wir jetzt sicher sind, dass die VM nicht mehr läuft schauen wir uns das SR (Storage Repository) an, auf dem das betroffene VDI liegt.
Um sicherzugehen, dass das SR kein grundsätzliches Problem hat, machen wir einen Testlauf mit einem neuen VDI.

In der GUI gehen wir in den Storage-Tab der VM und fügen ein neues VDI von 1GB hinzu, dass im gleichen SR liegt wie das betroffene VDI und nennen es “test”.

Jetzt suchen wir die zugehörige UUID des VDI per “xe vdi-list name-label=test”:

[root@ii-rx3-xen2 ~]# xe vdi-list name-label=test
uuid ( RO)                : 17f4d241-84e2-42d5-a66b-a9ed95947f70
name-label ( RW): test
name-description ( RW):
sr-uuid ( RO): 32f58c73-19c3-fab4-76f7-199ccfefb646
virtual-size ( RO): 1073741824
sharable ( RO): false
read-only ( RO): false

Die oberste UUID ist die gesuchte und jetzt lassen wir das VDI per “xe vdi-forget” verschwinden:

[root@ii-rx3-xen2 ~]# xe vdi-forget uuid=17f4d241-84e2-42d5-a66b-a9ed95947f70
[root@ii-rx3-xen2 ~]#

Wenn die Operation erfolgreich war, erscheint nur ein leerer Prompt und das VDI ist aus der VM und dem SR verschwunden.
Um es jetzt wieder herbeizuzaubern müssen wir das SR scannen und danach das VDI wieder benennen.
Hier brauchen wir die SR-UUID, die wir oben sehen:

[root@ii-rx3-xen2 ~]# xe sr-scan uuid=32f58c73-19c3-fab4-76f7-199ccfefb646
[root@ii-rx3-xen2 ~]#

[root@ii-rx3-xen2 ~]# xe vdi-param-set name-label=test uuid=17f4d241-84e2-42d5-a66b-a9ed95947f70
[root@ii-rx3-xen2 ~]#

Jetzt sollten wir das VDI wieder in der GUI sehen können.
Wenn bisher alles lief wie beshrieben, sollte das SR in Ordnung sein und wir können uns dem betroffenen VDI widmen.

Gab es Fehler,Warnmeldungen oder andere Ungereimtheiten sollte man jetzt lieber aufhören und sich das SR näher ansehen.

Jetzt wiederholen wir das ganze Prozedere mit dem betroffenen VDI, benenen es jedoch vorher um, damit wir nicht durch ev. vorhandenen alte Snapshots verwirrt werden.
Entweder man nimmt einen neuen kurzen Namen oder ergänzt am bisherigen Namen eine Erweiterung, z.B. _1

VDI-Property

Jetzt ermitteln wir wieder die UUID des VDI:

[root@iirxp4xen1 ~]# xe vdi-list name-label=ii-OTRS_kix_1
uuid ( RO)                : 853ab496-b432-4f00-863e-b4a32885ea52
name-label ( RW): ii-OTRS_kix_1
name-description ( RW): ii-OTRS + kix4OTRS
sr-uuid ( RO): 598eb519-52bb-acb6-e16b-a1175aeb279a
virtual-size ( RO): 10737418240
sharable ( RO): false
read-only ( RO): false

Lassen das VDI verschwinden:
[root@iirxp4xen1 ~]# xe vdi-forget uuid=853ab496-b432-4f00-863e-b4a32885ea52

Scannen das SR:
[root@iirxp4xen1 ~]# xe sr-scan uuid=598eb519-52bb-acb6-e16b-a1175aeb279a

Benennen das VDI neu:
[root@iirxp4xen1 ~]# xe vdi-param-set name-label=ii-OTRS_kix_1 uuid=853ab496-b432-4f00-863e-b4a32885ea52

Und sollten jetzt das VDI wieder in der GUI sehen können.
Als letztes fügen wir es wieder per “Attach” an die VM an, im Storage Tab der VM.

Storage-Attach

Und jetzt sollte sich die VM wieder normal starten lassen und wie gewohnt funktionieren.

Wenn die VM mehrere Disks hatte, müssen wir natürlich diese Prozedur für alle Disks wiederholen bevor die VM wirklich startet.

Diese Methode funktioniert auf jeden Fall für XenServer bis Version 6.2, unter 6.5 hatten wir das Problem noch nicht, es sollte aber genauso funktionieren.