Nie od dziś wiadomo, że XenServer pozbywa się technologii StorageLink. Ta swoista integracja macierzy SAN z hostami XEN okazała się piętą achillesową XenServer’a.
Przy migracji wirtalnych maszyn ze StorageLink na LVM zauważyłem dziwną przypadłość. O ile w trakcie migracji, każdy VDI jest przenoszony przy udziale dom0, to po zakończonym kopiowaniu powinien ten „uchwyt” zwolnić. Tak się jednak nie dzieje i każdemu dyskowi zostaje przypisany kolejny VBD (Virtual Block Device) wskazujący na hosta, który się zajmował jego migracją.
Na źródłowym i docelowym SR w zakładce „Storage” zauważyłem dyski, których wirtualnymi maszynami były „nazwa_VM” (oczywiste) oraz „Control domain on host hostname„.
Jak sobie radzić z tą sytuacją ?
1. Wyłączamy zmigrowaną wirtualną maszynę.
2. Hostowi Xen, który jest przypisany dla danego VDI wykonujemy komendę „Restart Toolstack”. Prawo-klik na hoście z poziomu XenCenter lub przez CLI : xe-toolstack-restart
3. Znajdujemy UUID dla VDI, które nas interesuje : xe vdi-list | grep -C5 "nazwa_dysku"
4. Szukamy wszystkie VBD podpięte pod ten VDI : xe vbd-list vdi-uuid=VDI_UUID
5. Odpinamy VBD od VM, którego atrybut „vm-name-label” to „Control domain on host ….” : xe vbd-unplug uuid=VBD_UUID
6. Usuwamy ten niepotrzebny VBD : xe vbd-destroy uuid=VBD_UUID
Szybszym sposobem jest znalezienie wszystkich VBD z atrybutem „Control domain on host” :
xe vbd-list | grep -C5 "Control domain"
ale wtedy musimy być pewni że VBD, które chcemy usunąć nie należy np. do metadanych puli na potrzeby Disaster Recovery.
Co o tym sądzisz ?