Hyper-v replication – Critical

repairHyper-v Replica – problemy

Hv Replica jest dobrą ideą – jednak wykonanie szwanqje. wiele operacji, jakie jest wykonywane w ramach HvR jest zabójcze dla niego samego. do tego zachowanie jest bardzo nieprzejrzyste – do powodu błędów trzeba mocno dociekać, opisy są zwodnicze, braqje narzędzi do bezpośredniego debugowania. mówiąc w skrócie – mechanizm zaprojektowany jest jako samograj, a niestety jest na tyle niestabilny, że ciągle trzeba przy nim grzebać i jest to ciężka systemówka.

replikacja przerzuca pliki wektorów zmian [.hrl]. kiedy zostanie przerzucony plik, następuje… łączenie [merge] plików vhd. o ile w przypadq małej zmiany i małego pliq wszystko sobie działa dobrze, o tyle przewalenie kilq GB pliq do zmerdżowania z np. 1TB dyskiem, jest operacją zabijającą mechanizm – nie ma możliwości skończyć się ani w 5min [standardowy czas przerzucania zmian HvR] ani w 15min [max. jaki można ustawić] a zdarza się, że i godzina byłoby za mało, jeśli dyski są na prawdę duże. operacja jest wykonywana po stronie odbiorcy i jest to operacja bloqjąca – w czasie, kiedy jest wykonywana, z maszyną nie da się nic zrobić, a nadawca dostaje informację, że replikacji nie można wykonać.

dodatkowym problemem jest fakt, iż operacja łączenia dysków nie jest w żaden sposób pokazywana przez interfejs. błędy wyglądają następująco:

serwer wysyłający

log Hyper-V-VMMS/Admin, Event ID: 32552,

Hyper-V could not replicate changes for virtual machine '<VMNAME>' because the Replica server refused the connection. This may be because there is a pending replication operation in the Replica server for the same virtual machine which is taking longer than expected or has an existing connection. (Virtual machine ID <VMGUID>)

 

log Hyper-V-VMMS/Admin, Event ID: 32315,

Hyper-V failed to replicate changes for virtual machine '<VMNAME>' (Virtual Machine ID <VMGUID>). Hyper-V will retry replication after 5 minute(s).

 

serwer odbierający

log Hyper-V-VMMS/Admin, Event ID: 15268 [nie występuje zawsze]

Failed to get the disk information.

log Hyper-V-VMMS/Storage, Event ID: 27000,

Failed to open attachment 'C:\ClusterStorage\VolumeX\Hyper-V Replica\Virtual hard disks\<VMGUID>\<DISKGUID>.avhdx'. Error: 'The process cannot access the file because it is being used by another process.'.

ponadto jest możliwość szybkiej weryfikacji przy pomocy PowerShell, weryfiqjąc status maszyny na serwerze odbierającym:

PS C:\scriptz\> get-vm <VMNAME>|select *status*

OperationalStatus          : {InService, ModifyingUpVirtualMachine}
PrimaryOperationalStatus   : InService
SecondaryOperationalStatus : ModifyingUpVirtualMachine
StatusDescriptions         : {In service, Modifying virtual machine}
PrimaryStatusDescription   : In service
SecondaryStatusDescription : Modifying virtual machine
Status                     : Modifying virtual machine
MemoryStatus               :

statusy wyraźnie pokazują – 'InService’ oraz 'ModifyingUpVirtualMachine’ – być może taki status jest również w innych scenariuszach, ale regularnie powtarzający się – może oznaczać tylko jedno. dyski się łączą.

dalsze konsekwencje

to za chwilę prowadzi to zmiany statusu repliki na 'critical’ i ustawienia wymuszenia resynchronizacji w następnym cyklu [standardowo chyba raz dziennie o 18.oo – godzinę można sobie ustawić]. jeśli ręcznie wymusi się powtórną próbę replikacji po zakończeniu operacji 'merge’, to wszystko powinno być ok i maszyna powinna się zacząć replikować. jeśli jednak zostawi się na automat, to do cyklu resync może minąć zbyt wiele czasu, a to będzie oznaczało faktyczny resync.

i tu dochodzimy do kolejnej maskrycznej operacji – resynchronizacja. jest to kolejna operacja bloqjąca, podczas trwania której sypią się backupy [lockowany jest VSS], a biorąc pod uwagą ile trwa czasu dla dużych dysqw, potrafi spowodować lawinowe błędy.

jak uniknąć części błędów

różnymi automatami – trzeba monitorować replikację i oskryptować całe rozwiązanie. można to zrobić w bardziej wyrafinowany sposób, można po prostu co jakiś czas wymuszać resync dla wszystkich maszyn.

jest też ciekawostka, która nigdzie nie jest opisana – w każdym razie nie trafiłem – podeślijcie linka, jeśli się mylę. póki co – wisienka na torcie, exclusive dla w-filesowiczów (;

kiedy poobserwuje się replikację, można zauważyć, że w pewnym momencie taski 'zawisają’. jeśli z powodów opisanych powyżej wykonuje się kilka resynchronizacji, nagle okazuje się, że pozostałe maszyny co i rusz, również wchodzą w stan 'critical’. ograniczeniem jest opcja definiująca ilość równoczesnych 'storage migration’, ustawiana we właściwościach Hyper-V. standardowo są to dwie operacje. nawet jeśli maszyny rozłożone są na kilq węzłach klastra, może okazać się, że jakieś dwie długie synchronizacje lub resynchronizacje, będą blokować pozostałe maszyny. dla tego warto ten parametr zwiększyć. to znacząco obniża ilość problemów!

ponoć w Windows 1o Server, mechanizm replikacji ma być wymieniony – ale również nie mogę znaleźć artykułu potwierdzającego ten fakt /:

będę wdzięczny za linki (:

eN.

 

wymiana certyfikatu dla hyper-v replica

informacji o tym jak skonfigurować – od groma. ale jak wymienić certyfikat… no więc proszę:

po wymianie certyfikatu na serwerze źródłowym Hyper-v Replica trzeba jeszcze zmusić go do korzystania z niego. okazuje się, że używany cert jest właściwością replikowanej maszyny. oznacza to, że zmianę trzeba wprowadzić dla każdej VMki. można klikać – jak się ma dwie-trzy maszyny może i się da. ale jak się ma ich *dziesiąt to trochę mało fajne. szczęśliwie jest … PowerShell (: jakże by inaczej.

  • zaloguj się na którymś z Hv [np. enter-pssession]
  • skopiuj thumbprint certyfikatu
cd cert:\LocalMachine\my
ls
  •  potem można myszką skopiować 'thumbprint’ tego, o który chodzi.
  • następnie trzeba wprowadzić zmianę dla maszyn. dla całego clustra sobie daruję, ale dla wszystkich VMek na pojedynczym hoście:
get-VmReplication|%{set-VMReplication -VMName $_.name -CertificateThumbprint "thumbrinthere000000"}

a potem można zrestartować usługę 'vmms’ żeby odświeżyć replikację.

i już

 

 

magia storage migration

wits„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.

jak sprawdzić przypisania wirtualnych kart sieciowych

klaster ma swoje wymagania co do sieci – potrzebuje kilku interfejsów do LM, HB, iSCSI, VLANy i tak dalej. jeśli tylu sieciówek nie ma, a zdarza się, że po prostu braqje portów na switchu (; i w kilq innych scenariuszach – czasem warto jest utworzyć wirtualne interfejsy. na stronach technetu można znaleźć ładną instrukcję więc nie będę kopiował. tutaj chciałem podać tylko mały trik. po założeniu owych wirtualnych interfejsów chciałoby się podejrzeć który jest dowiązany do którego wirtualnego switcha. trzeba przyznać, że konstrukcja wirtualnych switchy jest nieco zamota, a w połączeniu z VMM gdzie dochodzą jeszcze sieci logiczne staje się to na prawdę nieprzyjemne przy rozwiązywaniu problemów.

  • teoretycznie switche widać w hyper-v managerze… ale nie widać tak wirtualnych interfejsów.
  • interfejsy – czy to fizyczne czy wirtualne, widać w systemie – czy to z GUI 'ncpa.cpl’ czy z powershell 'get-netAdapter’. ale nawet wyświetlając wszystkie właściwości konkretnego interfejsu nie widać ich powiązań z VMSwitch
  • standardowo polecenie get-VMNetworkAdapter pokazuje powiązania z maszynami wirtualnymi……

..ale to już bardzo blisko rozwiązania. jest jeden magiczny przełącznik, który stanowi rozwiązanie:

get-VMNetworkAdapter -ManagementOS

po wykonaniu tej komendy pokazywane są nazwy switchy wirtualnych. teraz wystarczy sprawdzić który switch powiązany jest z która kartą fizyczną i voila:

 Get-VMNetworkAdapter -ManagementOS|%{echo "$($_.name) -> $((get-vmswitch -name $_.switchname).NetAdapterInterfaceDescription)"}

idąc jeszcze krok dalej: nazwy kart z poziomu systemu znów są inne.. kolejna warstwa. więc jeszcze informacja jaka jest nazwa interfejsu z poziomu systemu:

Get-VMNetworkAdapter -ManagementOS|%{
    $iDesc=(get-vmswitch -name $_.switchname).NetAdapterInterfaceDescription;
    $adapterName=(Get-NetAdapter -InterfaceDescription $iDesc).name;
    echo "$($_.name) -> $iDesc -> $adapterName"
}

eN.

zminiejszenie fizycznej wielkości dysq vhdx

dość standardowy scenariusz: zaczęło mi na lapq brakować przestrzeni więc zacząłem szukać co ją kradnie. jednym ze złodziei okazała się maszyna wirtualna z w7 – pomimo, że dysk skonfigurowany był jako 'dynamic’, cała maszyna na vhdx, to wielkość fizyczna jest taka sama, jak wielkość partycji w maszynie.

ładnie zdefragmentowałem dysk, shutdown i optymalizacja:

optimize-vhd <pathTo.vhdx>

nic. ani bajta

optimize-vhd <pathTo.vhdx> -mode full

…nadal nic – nawet bajta /:

czas poszperać. gdzieś na forum znalazłem informację, że jest bug w obsłudze vhdx i lepiej używać vhd. nie wierzę – szukam dalej. znalazłem kolejny ciekawy wpis – że jest błąd przełączniq 'full’ i lepiej używać 'quick’ choć wydaje się to nie mieć sensu. sprawdziłem, zachowuje się zgodnie z przewidywaniami, czyli nie ugryzł ani bajta. na dysq miałem bardzo mało miejsca, pomyślałem, że może optimize-hvd działa jak np. eseutil – tworząc kopię gdzieś w tempie a potem nadpisując. ciekawostka jest taka, że niestety z tej operacji nie ma żadnego raportu – ani w eventvwr, ani na ekranie. skopiowałem plik na dysk zewnętrzny i powtórzyłem próby – bez zmian.

rozwiązanie:

rozwiązanie trochę mnie zaskoczyło. kluczowym jest informacja z technetu:

Full scans for zero blocks and reclaims unused blocks. (Allowable only if the virtual hard disk is mounted read-only.)

aby kompresja zadziałała prawidłowo, trzeba najpierw podmountować dysk [hę?]  w trybie readonly:

Mount-VHD <pathTo.vhdx> -ReadOnly
Optimize-VHD <pathTo.vhdx> -Mode Full
dismount-vhd <pathTo.vhdx>

spodziewałem się, że przy wyłączonej maszynie mountowanie jest robione dynamicznie albo wręcz niepotrzebne. optymalizacja bez mountowania o niczym nie informuje – a mogłaby… zatem pozostaje wiedzieć (:

eN.

VMM Agent Status: access denied

WTF?w-files combo.

scenariusz: serwery Hv w kilq wersjach [2k8R2, w2k12, w2k12R2, clustry i standalone] zarządzane System Center Virtual Machine Manager 2o12 SP1. w pewnym momencie nie da się założyć nowej maszyny wirtualnej, ponieważ 'rating’ pokazuje wszystkie maszyny jako niedostępne, nie da się zrobić Live Migration. w 'Fabric’ status agentów opisany jest jako 'Access Denied’.

pierwsza próba – 'sprawdź o co chodzi’ – czyli wywalenie agenta z maszyny i ponowne dodanie. wpis w logu:

Error (2927)

A Hardware Management error has occurred trying to contact server SCVMM04.hosting.netwise.pl .

WinRM: URL: [http://<hostFQDN>:5985], Verb: [INVOKE], Method: [AddPeerCertificate], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/AgentManagement]

Unknown error (0x80338113)

Recommended Action

Check that WinRM is installed and running on server <hostFQDN>. For more information use the command "winrm helpmsg hresult" and http://support.microsoft.com/kb/2742275

przeszukałem net i najwięcej artów dotyczyło konfiguracji winRM. [how to troubleshoot winrm] ale testy winrm bez problemy przebiegały – zarówno lokalnie, jak zdalnie, winrm id -r:<remoteHost>, bez zająknięcia czy opóźnień ślicznie odpowiada. w logach biało jak w staropolskiej zimie na ziemiach wschodnich. ktoś sugeruje, że wystarczy uruchomić agenty SCVMM. lame /: gdzieś indziej znajduję poprawki dla w2k8R2 żeby obsługiwała nowe serwery ale dawno zainstalowane. w ogólnym ’how to troubleshoot’  na stronach technet też nic ciekawego. wszystkie testy sieciowe przebiegają pomyślnie, FW na wszelki wypad wyłączyłem, żeby mieć pewność. w końcu trafiam na roqjący pozytywnie wpis dotyczący różnic  w wersji winRM… ale wszędzie mam v3 jak trzeba.

czas leci, godziny są palone, a VMM odmawia współpracy. stawiam nowego VMM – 2o12R2 – upgrade i tak był wpisany w kalendarz, więc zamiast ślęczeć nad debugowaniem po prostu stawiam od nowa.

jak nie ciężko się domyśleć – nadal nie działa – tym razem, tak dla odróżnienia, już nie na wszystkich maszynach. w końcu się wkurzyłem i zmieniłem dwa ustawienia w polisie GPO:

Turn On Compatibility HTTP Listener Disabled -> Enabled
Turn On Compatibility HTTPS Listener Disabled -> Enabled

w zasadzie nie ma to sensu bo compatibility listeners są dla winRM1.1 w w2k3 a takich wynalazków szczęśliwie nie ma. gpupdate na wszystkich maszynach. i działa /:

to była ciekawostka #1 a teraz ciekawostka #2. tak bardzo nie rozumiem dla czego to się tak zachowało [ i wszystkie commandlineowe testy przebiegają poprawnie i część funkcjonalności działa i PSremoting działa…] że postanowiłem te polisy z powrotem wyłączyć.

Turn On Compatibility HTTP Listener Enable-> Disabled
Turn On Compatibility HTTPS Listener Enabled -> Disabled

gpupdate na wszystkich hostach… i dalej działa @_@ w każdym razie póki co. restartów nie robiłem i minęło kilka h. teoretycznie jakby miało przestać to już by nie działało. nie potrafię tego wyjaśnić.

eN.

 

zdalne odinstalowanie agentów VMM

automationscenariusz: upgrade VMM 2o12 -> 2o12 R2. nie ma inplace upgrade, więc stawiany obok. agentów również nie chce zainstalować z automatu na hostach bo 'version is not supported’. trzeba więc w pierwszym kroq odinstalować wszystkie agenty na wszystkich hostach. jeśli tylko jest dobra [czyli skrypto-przyjazna] notacja nazewnicza, to można to zrobić szybko, sprawnie i bez bólu. taki przykład – dla dziewięciu hostów o nazwach hvhosto1-o9. wymaganie: skonfigurowane winRM:

1..9|%{invoke-command -ComputerName hvhost0$_ -scriptBlock {gwmi -Class win32_product|? name -like '*virtual machine manager*'|%{$_.uninstall()}}}

eN.