0 Komentarzy Steps (7 total)
1. Extend the volume/LUN from the SAN management console
2. xe sr-list name-label= (note the uuid of the SR)
3. pvscan | grep [SR UUID] Note the device name (e.g. PV /dev/sdj )
4. echo 1 > /sys/block/device/device/rescan (e.g. echo 1 > /sys/block/sdj/device/rescan )
5. pvresize (eg: pvresize /dev/sdj)
6. xe sr-scan uuid=[SR UUID]
7. Verify that the XE host sees the larger physical disk: pvscan | grep [SR UUID]
0 Komentarzy 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ą ?
