Kategoria: SystemCenter

magia storage migration

„tyle magii w całym mieście,

nie widziałeś tyle jeszcze,

popatrz.. o popatrz…”

dzisiejszy dzień mianuję swoim 'dniem archeologa’. podstawowe założenia – cuda nie istnieją. ale kategoria i tak do w-files. a wszystko zaczęło się od zupełnie zwykłego taska administracyjnego opisywanego w poprzednim wpisie: trzeba usunąć CSV i stworzyć nowy. czyli musi być jakiś pośredni – temp, i maszynki trzeba przenieść najpierw na tempa, dokonać odpowiednich modyfikacji na macierzy, stworzyć nowe CSV i na nie poprzenosić już docelowo maszyny. no i się zaczęło…

podczas przenoszenia maszyn, wszystko idzie sprawnie, aż na koniec informacja, że migracja nie powiodła się. efekty różne łącznie z takim, że maszyna po prostu znika! (SIC!) ale żeby jeszcze zupełnie znikęła, a to nie – niby jest a jej nie ma. niby jej nie ma, a jest… no po prostu burdel na kółkach. ale udało się dużą część wyjaśnić…

finalnie okazało się, że są dwa powody nieudanych migracji: jeden to snapshoty DPM a drugi to jakiś wewnętrzny błąd SCVMM, którego póki co nie umiem wyjaśnić.

1. DPM.

błąd

przypadek ciekawszy, ponieważ po wykonaniu migracji maszyna jest, ale jej nie ma. błąd migracji:

Error (2901)
The operation did not complete successfully because of a parameter or call sequence that is not valid.
The parameter is incorrect (0x80070057)

Recommended Action
Ensure that the parameters are valid, and then try the operation again.

maszyna pozostaje w VMM z informacją 'incomplete VM Configuration’. jest również widoczna w klastrze, ale zasób konfiguracji jest niedostępny. natomiast, żeby było ciekawie, zostaje wyrejestrowana z samego hosta Hv. po analizie logów na hoście Hv, na którym maszyna była zarejestrowana pojawiają się na koniec migracji trzy wpisy:

• Event ID 18303 'The Virtual Machine Management service successfully completed the export operation of virtual machine’
• Event ID 13003 'The virtual machine '<VMName>’ was deleted’
• Event ID 16300 'Cannot load a virtual machine configuration: The system cannot find the file specified. (0x80070002).

wnioski

owy plik, który cannot be found to snapshot zrobiony przez DPM. okazuje się, że w wyniq utraty komunikacji w trakcie robienia backupu, DPM zostawia informację o snapshocie. specjalnie napisałem 'informację’ ponieważ okazuje się, że jest xml z informacją, widać go w interfejsie tudzież używając get-vmsnapshot, ale sam katalog, gdzie powinny znajdować się pliki snapshota (vsv i bin), jest pusty. sam proces 'storage migration’ działa jako: export VM -> delete VM-> import VM, wywala się na ostatnim kroq. maszyna zostaje usunięta z Hv, a durny VMM nie zapewnia atomowości. nie dość, że migracja się nie udaje, zostają pełne zapisy w clustrze i VMM, sama maszyna znika.

rozwiązanie

po fakcie jest tylko jeden sposób:

• usunąć zasób klastra
• zaimportować maszynę. zapyta nas o położenie checkpointów – trzeba usunąć, bo ich tak na prawdę nie ma
• dodać zasób do klastra

a żeby zapobiec, najlepiej zrobić hurtowe zapytanie o snapshoty typu recovery i je pousuwać. łatwo odróżnić te, które są 'w trakcie’ do tych, które wiszą, ponieważ w nazwie mają daty:

VMName      Name                                   SnapshotType CreationTime
------      ----                                   ------------ -----------
VMo1        VMo1 - Backup - (2014-11-19 - 23:19:08)Recovery     2014-11-...
VMo2        VMo2 - Backup - (2014-11-19 - 23:44:42)Recovery     2014-11-...

widać, że to są jakieś snapy z przed wielu dni, więc na pewno do wywalenia. po upewnieniu się, że wszystkie są stare i żaden backup teraz się nie wykonuje:

Get-ClusterNode -Cluster <CLUSTER>|%{$h=$_.name;get-vm -VMHost $h|%{Get-VMSnapshot -ComputerName $h -VMName $_.name|? snapshotType -eq 'recovery'|Remove-VMSnapshot}}

następnie warto odświeżyć VMM, ponieważ ma stare informacje. można np. hurtem wszystkie maszyny: get-scVirtualMachine|read-scVirtualMachine|out-null

2. zła nazwa

błąd

drugi przypadek jest dziwny i wygląda na wewnętrzny błąd VMM. migracja wywala się w ostatnim etapie z błędem o niedostępności zasobu. po weryfikacji okazuje się, że maszyna jest jednak zmigrowana i dyski wskazują na nowy CSV. jeśli jednak spojrzy się do konsoli klastra okazuje się, że maszyna ma w zależnościach wpisy dotyczące i starego i nowego CSV. to dokładnie efekt opisywany ostatnio.

analiza polega na spostrzegawczości. błąd migracji jest następujący:

Error (12711)
VMM cannot complete the WMI operation on the server (<HOSTNAME.FQDN>) because of an error: [MSCluster_Resource.Name=&quot;SCVMM VMNAME Configuration&quot;] Element not found.

Element not found (0x490)

Recommended Action
Resolve the issue and then try the operation again.

natomiast po przyjrzeniu się wynikom czy to z PS czy w interfejsie widać, że maszyna nazywa się po prostu 'VMNAME’ a nie 'SCVMM VMNAME’ /:

wnioski

VMM jest głupi.

rozwiązanie

post factum można to zrobić tak, jak we wspomnianym wpisie – czyli przez WMI usunąć z privateparts zależność do dysq. można to też zrobić prościej – i metoda powinna dać efekt post factum et pro eo – odświeżyć konfigurację maszyny na klastrze:

Update-ClusterVirtualMachineConfiguration -Cluster <CLUSTER> -name 'Virtual Machine Configuration <VMNAME>'

 3. to nie koniec magii

a bo inne ciekawe przypadłości podczas całej operacji wyszły, mniej-lub-bardziej wyjaśnialne. ot np. taki niuans:

jedna maszyna ma w VMM status 'incomplete VM configuration’ a VMM pokazuje, że maszyna jest na hoście HOSTo3. w klastrze ta sama maszyna działa i ma się dobrze, i działa na hoście HOSTo5. póki co nijak nie udało mi się odświeżyć tej maszyny. prawdopodobnie trzeba to będzie zrobić via SQL. ale jeszcze fajniejsza rzecz:

PS C:\scriptz> get-vm -VMHost HOSTo3|select name

Name
----
VMo1
VMo2
VMo3

załóżmy, że ta VMo2 to ta, której nie ma. to samo polecenie dla hosta, na którym ta maszyna działa, nie pokazuje jej. ale przecież Hv manager jej nie pokazuje, i jej tam nie ma! o co c’mon? otwieram drugą konsolę, kopiuję polecenie i…

PS C:\Users\nz.adm> get-vm -VMHost HOSTo3|select name
Get-VM : A parameter cannot be found that matches parameter name 'VMHost'.
At line:1 char:8
+ get-vm -VMHost HOSTo3|select name
+        ~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Get-VM], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.HyperV.PowerShell.Commands.GetVMCommand

eeeee.. ale że o co c’mon? i znów na spostrzegawczość: przecież get-VM nie ma parametru 'VMHost’ tylko 'ComputerName’ – co zresztą podpowiada tab. zatem muszą to być dwa różne polecenia… oto odpowiedź:

konsola A

PS C:\scriptz> Get-Command get-vm

CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Alias           Get-VM

PS C:\scriptz> man get-vm
NAME
    Get-SCVirtualMachine
SYNTAX
    Get-SCVirtualMachine [[-Name] <string>] [-VMMServer <ServerConnection>] [-All] [
    fOfUserRole <UserRole>]  [<CommonParameters>]

konsola B

PS C:\scriptz> Get-Command get-vm
CommandType     Name                                               ModuleName
-----------     ----                                               ----------
Cmdlet          Get-VM                                             Hyper-V

PS C:\scriptz> man get-vm
NAME
    Get-VM
SYNTAX
    Get-VM [[-Name] <string[]>] [-ComputerName <string[]>]  [<CommonParameters>]

 wnioski

VMM jest nie tylko głupi, ale również wredny.

eN.