kopiowanie plików na VM

nie qmam polityki eMeSa, który zdając sobie sprawę z wagi wirtualizacji, ubił środowiska wirtualizacyjne na stacjach roboczych. Hv na lapq ma wiele wad, ale jedna z nich została usunięta. w końcu można kopiować pliki bezpośrednio na maszynę… szkoda, że nie w drugą stronę, ale od czegoś trzeba zacząć q:

pełny opis zamieściłem tutaj.

eN.

 

 

SCVMM – jest sieć… a nie ma

scenariusz: jest sobie SCVMM i podpięte do niego ileś-tam hostów. na wszystkich mam utworzoną sieć „External” z dostępem public, z której korzystają virtualki. tworzę nową maszynę i host, na którym chcę ją utworzyć, dostaje w „rating o”. VMM odmawia utworzenia maszyny na tym hoście a w wyjaśnieniach takiej oceny jest informacja, że nie ma takiej sieci jak „External”. dodam jeszcze, że na tym hoście działa normalnie inna VM podpięta do tej sieci, i wszystko jest prawidłowo.

sprawdzam w VMSwitch w VMMie. porównuję z innymi hostami. nic. sprawdzam bezpośrednio na Hyper-v żeby wyeliminować jakiś błąd czy desynch w informacjach na VMM. ale wszędzie, wszystko wygląda ok. postanawiam zmusić do utworzenia virtualki żeby dostać jakiś sensowny błąd – i tak też się dzieje. tworzę VM bez przypisania do sieci i kiedy po poprawnym utworzeniu zmieniam sieć na „External” pojawia się:

Error (26894)
VM Network (External) is unavailable on Virtual Switch (External)

dziwne. okazuje się, że są wewnętrznie dwa obiekty – VM Network i VM Switch. VM Switch istnieje, tylko sieci nie ma. ale żadnej metody utworzenia takiej sieci również nie ma – ani z PS ani z interfejsu /: przyjrzałem się konfiguracji przypisań sieci do sieciówek. okazało się, że w wyniq jakiegoś błędu, sieć jest przypisana do jednej karty NIC, a VM Switch do drugiej. po zmianie przypisania NIC na poziomie VM Switcha – wszystko zaczęło śmigać. a tak to wygląda w obrazkach:

w widoq VMM/VM proerites/Hardware przy powiązaniu kart sieciowych z sieciami wirtualnymi widać, że sieciówka o numerze #87 nie ma dowiązania z żadną z nich. strzałka pokazuje na 'External’, które jest dowiązane do drugiego interfejsu.

props1

dla sieciówki #87 'External’ nie jest dowiązane

prop2

w interfejsie nie widać pełnych nazw – niestety są poucinane ze względu na długość. dla tego najlepiej upewnić się z PS:

Get-VMSwitch external|fl *

ComputerName                        : COMPUTERNAME
Name                                : External
Id                                  : db819d9e-26ab-4282-89f7-12e0436a3f38
Notes                               :
SwitchType                          : External
AllowManagementOS                   : True
NetAdapterInterfaceDescription      : Broadcom BCM57810 NetXtreme II 10 GigE (NDIS VBD Client) #87

 

jak widać – VM Switch związany jest z #87 a sieć wirtualna z fizyczną #86. i zrobił się split…

eN.

pomniejszanie dysq

w zasadzie od w2k jest możliwość pomniejszania/powiększania dysqw bezpośrednio z disk managera. z niewiadomych powodów, z każdą wersją, powolutq, była dodawana nowa funkcja – w NT5.o tylko extend, w NT6.o extend i shrink ale max do 5o% powierzchni izdaje się, że nie można było ruszyć boot partition i system partition, w NT6.1 znów zniesiono obostrzenia aż do NT6.3 gdzie teoretycznie można sobie zmniejszać i zwiększać bez problemu…

to tyle, jeśli chodzi o teorię – czas na trochę praktyki, bo [jak to usłyszałem ostatnio qilqrotnie w ciągu krótkiego czasu] życie weryfiqje. obostrzenia oczywiście są. pierwszym z nich są 'nieprzenaszalne pliki’ – czyli takie, do których system trzyma konkretny adres i z pewnych względów nie może ich ruszyć. do takich należą np. restore points, pagefile, klucze BitLocer i kilka innych specyficznych obiektów. przy próbie zmniejszenia dysq, system automatycznie wylicza przestrzeń do pierwszego takiego pliq, wskazując maksymalną wielkość, o którą można dysk zmniejszyć.

scenariusz na jaki trafiłem, i skąd bierze się ten wpis jest taki, że po miesiącu pracy dostałem nowego kompa. przeniesienie się jest zawsze mało przyjemne, bo pomimo, że prawie wszystko jest w chmurze, zawsze zostaje sporo poinstalowanych i skonfigurowanych już aplikacji. BUUUEEEH. ponowna instalacja śmierdzi. prosty wniosek – zrobię z tego VHDX, skopiuję na nowego kompa i będę sobie bootwał z niego. proste. tyle, że okazało się, że w jednym kompie jest 5ooGB a w nowym 12oGB dysq. system nie pozwala zmniejszyć dysq o tak dużą wartość. co zrobić?

w pierwszej kolejności trzeba sprawdzić co nas bloqje. w suqrs przyjdzie zajrzenie do eventloga Application i przefiltrowanie po zdarzeniach z ID 259. zdarzenie to jest generowane przez … defrag [sic!], w momencie, kiedy włączamy wizarda w diskmanagerze:

EventID 259
 A volume shrink analysis was initiated on volume (C:). 
This event log entry details information about the last unmovable file that could 
limit the maximum number of reclaimable bytes.
Diagnostic details:
 - The last unmovable file appears to be: \System Volume Information\FVE2.{e40ad34d-
dae9-4bc7-95bd-b16218c10f72}.3::$DATA
 - The last cluster of the file is: 0x4d93bba
 - Shrink potential target (LCN address): 0xac8878
 - The NTFS file flags are: ---AD
 - Shrink phase: <analysis>

FVE2 to właśnie klucz BL. swoją drogą przy bootowaniu systemu z VHDX trzeba pamiętać, że BL nie jest obsługiwany. nie jest również obsługiwana hibernacja. to tak zanim się podejmie decyzję, czy na pewno ta droga jest prawidłowa. wyłączyłem BL, wyłączyłem Restore Points, i wyłączyłem… czy też chciałem wyłączyć Pagefile. już nie pierwszy raz zdarzyło mi się, że pomimo wyłączenie PF i restartu, ten wracał jak boomerang. dopiero konfiguracja z linii poleceń faktycznie się go pozbyła

wmic pagefileset delete

jeszcze ręczne wyczyszczenie katalogu System Volume Information i voila! po uruchomieniu wizarda zmniejszania dysq mogę go sqrczyć do maleńkości… szkoda tylko, że kiedy próbuję – dostaję komunikat, że system nie może zmniejszyć partycji ponieważ… wybrałem za dużą wartość /: tutaj rozwiązaniem okazało się krokowe zmniejszanie – najpierw 2ooGB a potem po 5oGB… i jakoś system to przełknął. ciężko powiedzieć zatem po co ten komunikat i o co cho.

teraz disk2vhd i prawie już. prawie, ponieważ disk2vhd nie ma opcji wyboru, jaki typ dysq chcemy uzyskać – jest na sztywno dynamic. no i trzeba mu zmniejszyć wielkość – bo o ile partycja jest sqrczona, to sam dysk pozostaje wielki. i tu kolejne zaskoczenie. kiedyś były toole, które na plikach vhd łatwo i przyjemnie robiły takie operacje. od czasu, kiedy wszystkie narzędzia są dostępne w systemie, i pojawił się format vhdx, narzędzi brak. systemowe narzędzia natomiast mają podstawową wadę – PowerShellowe commandlety Convert-VHD czy Resize-VHD wymagają, aby w systemie działała usługa Hyper-v. niby nic… a jednak cyc. nie udało mi się znaleźć żadnego darmowego toola, który by wykonywał operacje na dyskach vhdx.

ponieważ ta instancja systemu i tak była do wyrzucenia, a poszukiwania były raczej z takiej ciekawości i niedowiary, zainstalowałem Hv, skonwertowałem dysk, potem kopia na nowy, bcdboot i w końcu sukces. ale i tak, pomimo, że finalnie zabrało mi to tyle samo czasu co instalacja system+aplikacje, było to zajęcie dużo przyjemniejsze q:

eN.

VMConnect

niedawno pisałem o tym, co można zrobić z hosta maszynie wirtualnej. przy okazji dalszych poszukiwań poczytałem sobie o VMConnect.exe – czyli jak w zasadzie działa zdalny pulpit to VM? najciekawsze jest,  że jest to zdalny pulpit – ale przecież można się połączyć zanim w ogóle wystartuje system. po zainstalowaniu RSAT dla Hv vmconnect znajduje się w „C:\Program Files\Hyper-V” i można pobawić się z linii poleceń. wymagane są dwa paramtry: nazwa hosta oraz maszyny wirtualnej, przy czym nazwa VM może być w postaci nazwy lub VMID. kilka ciekawostek o VMConnect i PS można przeczytać tutaj.

pozostaje jeszcze jedna ciekawostka – na Hyper-v Server nie ma GUI i nie ma VMConnect. ciekawszym scenariuszem jest zarządzanie z Linuxa… okazuje się, że na codeplexie jest alternatywa – FreeRDP.

eN.

 

zarządzanie VM z hosta Hv

środowiskiem zarządza się z jakichś narzędzi infrastrukturalnych typu System Center – to oczywiście najlepszy sposób ale w pewnych warunkach mało przydatny lub niemożliwy. zarządzanie w tej warstwie jest niemal niemożliwe/totalnie skomplikowane w środowisq hostowanym – wiele domen nie powiązanych ze sobą, maszyny w podsieciach porozdzielanych VLANami, inne przestrzenie nazewnicze i tak dalej… efekt jest taki, że nawet jeśli dla narzędzi uwierzytelnienie w wielu domenach nie jest problemem, pozostaje bardzo skomplikowany schemat sieci i bezpieczeństwa – często niezależny od administratora i zarządzany przez klienta.

fajnie byłoby móc to wszystko ogarnąć z jednego, centralnego punktu – klastra Hyper-V, gdzie te wszystkie hosty sobie działają. skoro mam je w jednym miejscu logicznym się wydaje, aby z niego wykonywać pewne operacje maintenancowe czy administracyjne [oczywiście jeśli taka jest umowa z klientem]. na każdym guescie powinny być Integration Services, Hv komuniqje się z IS i … co możemy dzięki temu zrobić?

nic. w każdym razie bardzo niewiele. powód jest prosty – z założenia całość musi być bezpieczna a Hv ma być warstwą izolującą. nie bez powodu w Hv w konsoli zdalnej nie ma możliwości mountowania dysków czy nawet schowka. Hv ma pozostać możliwie najcieńszą i najbezpieczniejszą warstwą.

co zatem jednak można oraz jak sobie z takim środowiskiem poradzić?

root\virtualization

popatrzmy co nam daje WMI z poziomu hosta. skoro można coś zrobić z poziomu SCVMM to znaczy, że da się z konsoli w postaci skryptu. obszerna lista klas pozwala na pełną konfigurację i odpytanie maszyny – oczywiście od strony 'wirtualnego hardwareu’ – czyli nadal nie to, co mnie w tej chwili interesuje, ponieważ chciałbym dostać się do OSa. i tutaj z ciekawszych klas można znaleźć:

  • MSVM_ComputerSystem – podstawowa klasa, pozwalająca dowiedzieć się czegoś o samym OS. informacje nie są jednak dostępne bezpośrednio z tego obiektu – trzeba informacje 'wymienić’ między hostem a guestem, a robi się przy pomocy klasy…
  • Msvm_KvpExchangeComponent – to podstawowy komponent służący do wymiany informacji między hostem i guestem. dzięki kombinacji tych dwóch klas można m.in. sprawdzić: FQDN systemu, skonfigurowane adresy IP, wersję systemu i SP itp. to podstawowa klasa pozwalająca na dalszą automatyzację – nazwa maszyny wirtualnej jest zupełnie nie przydatna poza kontextem samego SCVMM/HvM. aby połączyć się czymś do VM trzeba będzie to zrobić 'oficjalnie’ czyli via sieć. a do tego potrzebny jest IP, który można uzyskać właśnie z tej klasy.
  • kilka innych klas 'Integration Services’ pozwalających na interakcję z wewnętrznym OSem – shutdown, timesync i VSS. szczególną uwagę zwraca – Msvm_GuestFileService i Msvm_CopyFileToGuestJob – dostępne od wersji Windows 8.1. zdaje się, że wraz z R2 będzie można w końcu normalnie kopiować pliki q: pojawia się też inne klasy sugerujące, iż ilość operacji jakie będzie można wykonać z hosta będzie się rozszerzać.

praktyka

jednym z przydatniejszych skryptów jaki często wykorzystuje jest Get-VMDetails wykorzystujący powyżej opisane klasy. importuję go jako funkcję dzięki temu na stacji zarządzającej jest zawsze dostępny:

function Get-VMDetails
{
    Param(
        [Parameter()]
        $ComputerName = $Env:ComputerName,

        [Parameter()]
        $VMName
    )

    $HashTab = @{}

    # Getting VM Object
    $Vm = Get-WmiObject -Namespace root\virtualization -Query "Select * From Msvm_ComputerSystem Where ElementName='$VMName'" -ComputerName $ComputerName

    # Getting VM Details
    $Kvp = Get-WmiObject -Namespace root\virtualization -Query "Associators of {$Vm} Where AssocClass=Msvm_SystemDevice ResultClass=Msvm_KvpExchangeComponent" -ComputerName $ComputerName

    # Converting XML to Object
    foreach($CimXml in $Kvp.GuestIntrinsicExchangeItems)
    {

        #$XML = [xml+site:msdn.microsoft.com">XML]$CimXml
        $XML = [XML]$CimXml

        if($XML)
        {
            foreach ($CimProperty in $XML.SelectNodes("/INSTANCE/PROPERTY"))
            {
                switch -exact ($CimProperty.Name)
                {
                    "Data"      { $Value = $CimProperty.VALUE }
                    "Name"      { $Name  = $CimProperty.VALUE }
                }
            }
            $HashTab.add($Name,$Value)
        }
    }
    New-Object -TypeName PSCustomObject -Property $HashTab
}

funkcja wypluwa obiekt dzięki czemu łatwo jest potem dalej odpytywać o poszczególne atrybuty. przykładowe użycie:

Get-ClusterNode -cluster <CLUSTERNAME>|%{$nodename=$_;get-vm -ComputerName $_|%{Get-VMDetails $nodename $_.name}}

#with specyfic info
Get-ClusterNode -cluster atmcluster|%{$nodename=$_;get-vm -ComputerName $_|%{$vmo=Get-VMDetails $nodename $_.name; echo "$($vmo.FullyQualifiedDomainName);$($vmo.NetworkAddressIPv4)"}}

środowisko

ostatecznie daje to tylko podstawowe informacje pozwalające na dalsze podłączanie się do maszyn. z samym system z tego poziomu nie zrobi się wiele więcej. nic zatem nie zastąpi odpowiednio przygotowanego środowiska tak, aby z centralnego punktu można było do maszyn się podłączyć.

można by poudostępniać sieci guest-VLAN dla hosta aby z jego poziomu dostawać się VMek. ale uważam, że to nie jest najlepszy sposób… izolację lepiej pozostawić. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów będące punktem styq. takim punktem mogą być  np.:

  • stacje monitorujące. np. nagios, open manage czy inne wynalazki. zależnie od polityki być może da się utworzyć stację, która będzie miała dostęp do wszystkich VLANów
  • system AV
  • system backupów
  • system dystrybucji poprawek

ponieważ klienci mogą nie wyrazić takiej zgody lub środowiska muszą być odizolowane w 1oo% z jakiś względów – pozostaje utworzenie kilq stacji w różnych sieciach, nawet jeśli wszystkie VM są na pojedynczym klastrze. fajnie byłoby mieć możliwość instalacji 'superagenta’ – który pozwoliłby na pełny dostęp do VM z hosta po uwierzytelnieniu – IMHO jeśli ktoś ma uprawnienia/zalecenia do maintenancu maszyny, security nie powinno cierpieć szczególnie pozwalając na dodatkową metodę dostępu…

refs

Hyper-v integration services

do tej pory nie miałem problemow z ‘enlightments’ – czyli Integration Services dla systemu operacyjnego do współpracy z Hyper-v. po pierwsze dla w2k3 trzeba było instalować zawsze, po drugie w2k8 i w2k8R2 mają je wbudowane.

jeśli jednak zostawi się standardowe wersje na w2k8 R2 na Hv v3 [czyli na w12] to zaczynają się dziać różne dziwne rzeczy. np. potrafi się wywyalić CSV [w eventlogu wpisy o błędach ze sterownikiem dla vhd], czasem nie działa prawidłowo sieć – mieliśmy teraz guesta, który gubił 4o% pakietów, i inne drobniejsze wypadki. a więc – jest to ważne, aby je zupdateować. a ponieważ od w2k8 są one od razu w systemie, nie zawsze się o tym pamięta. jak hurtem sprawdzić wersje IS na guestach?

dla pojedynczego hosta jest to trywialne:

get-vm |%{ echo "$($_.name) -> $($_.IntegrationServicesVersion)"}

trochę bardziej [ale nie tak znowu bardzo] kompliqje się to na clustrze. można oczywiście ręcznie wykonywać host-by-host ale bardziej pro jest zrobić to jednolinijkowcem (:

wykonanie ‘get-vm –computername <clustername>’ zwróci wyniki wyłącznie z jednego węzła. trzeba więc wylistować węzły i przekazać listę do kolejnego wykonania przytoczonego polecenia:

Get-ClusterNode -cluster <NAME>|%{get-vm -ComputerName $_ |%{echo "$($_.name) -> $($_.IntegrationServicesVersion)" } }

więcej poleceń dla klastrów:

Get-Command -Module failoverclusters

P.S. wychodzi na tym przykaładzie problem, z jakim boryka się cała idea PowerShell – podany przykład działa tylko dla w12. na w2k8 nie ma modułu dla Hv. co prawda jak cluster jest na w2k8 to i nie ma problemu z IS niemniej globalnie, jeśli chce się coś zrobić na Hv na w2k8 to trzeba sobie radzić inaczej – albo via WMI albo instalować moduły z sieci. a jeśli środowisko jest mieszane… zaczyna się robić nieprzyjemnie /:

eN.

Hyper-v replication v1.o?

znaczenie wersji produktów/ficzerów w Microsoft:

  • v1.o – marketing czyli ‘mamy taki produkt, jesteśmy na rynq!’. w rzeczywistości nie zdatny do użytq – po prostu ładnie wygląda na reklamie i informuje, że eMeS wyraża zainteresowanie tym fragmentem rynku
  • v2.o – początek, czyli – ‘mamy taki a taki produkt, potrafi to i to, nie potrafi jeszcze tego i tego, ale SOHO/SMB ma już pewne funkcjonalności za free’. w rzeczywistości – hmmm.. faktycznie działa.
  • v3.o – wdrażamy w ENT. w rzeczywistości – można wdrażać w ENT, bo faktycznie już jest skalowalny i większość funkcji nie dość że jest, to działa dobrze.

w w12 jest PowerShell v3.o oraz Hyper-v v3.o – oba naprawdę fajne i dojrzałe. a do Hv dodano nową, świetną funkcjonalność – Hv Replication… i jest ona ewidentnie w v1.o.. no może v2.o. o samej konfiguracji już trochę pisałem. czas na opis samej funkcjonalności.

co można o niej powiedzieć – jest. pomysł zaiste przedni – na miarę VMWare SRM. do tego stopnia fajnie pomyślane, że pozwala na wykorzystanie w scenariuszu hostingowym, gdzie stacje nie są w tej samej domenie. zacnie. skoro backup na hostingu – to znaczy łącze jakieś-takie. w sensie, że nie LAN 1GB. i teraz dochodzimy do clue, czyli to, co w całej świetności zostało spartaczone do stopnia nieużywalności. a są to dwa podstawowe ‘mankamenty’ + jeszcze trochę:

  • miejsce docelowe replikacji ustawiane jest per cały cluster a nie per replikowana maszyna wirtualna.
  • replikacja wykonywana jest co 5 min. i nie inaczej.

konsekwencje:

– jeśli chce się zrobić replikę całego clustra Hv, to wszystkie maszyny pchane są na pojedynczy storage. nawet jeśli maszyny-źródła są rozlokowane na wielu CSV dla zwiększenia wydajności, to docelowo będą przechowywane na pojedynczym. czyli jeśli strzeli podstawowa serwerownia, to zapasowa i tak może nie unieść takiego obciążenia. w efekcie można stosować albo dla bardzo małych środowisk – jedna, dwie maszyny, albo dla bardzo bogatych – gdzie jest się w stanie dostarczyć infrastrukturę [macierz, switche, NIC etc] potrafiącą unieść ‘takie’ obciążenie na jedym CSV. ‘takie’ – testowaliśmy to myśląc o redundancji dla klienta, gdzie na źródlanym klastrze stoi ok. 4o produkcyjnych maszyn. jedynym ratunkiem jest dodatnie do naszego DRP kroku pod tytułem ‘storage migration’ – czyli w trakcie uruchamiania maszyn w naszej lokalizacji offsite, równolegle migrujemy je na inne/docelowe CSV. odpalenie 4o wirtualek na jednym CSV po prostu się nie uda.

– no i najgorsze z najgorszych – czyli te nieszczęsne 5 min. ktoś, kto to zaharcodował musiał być po ciężkiej nocy – nie wnikając czy chodzi o pracę, czy zabawę, ale na pewno miał zaćmienie. replikowane są oczywiście delty – super. Mierzyliśmy je i nawet przy produkcyjnej maszynie nie są to *standardowo* duże zmiany – ot, 2-4MB. nawet dla 4o maszyn, przy 1oMbps łączu – 5min [teoretycznie i przy pełnej przepustowości] powinno wystarczyć. ale często, zbyt często, na maszynach produkcyjnych pojawiają się zmiany dużo większe – transakcje sql przy operacjach maintenancowych, operacje na serwerze plików, gdzie wrzuca się duże wielości czy tymczasowe pliki zrzucane przez aplikacje. nieszczęsny DPM potrafi na chwilę wrzucić 5GB plik. nie ma niestety możliwości utworzenia wykluczenia dla katalogu czy typu pliq – co w jakiś sposób by zminimalizowało problem w związq z czym trochę matematyki:

  • załóżmy, że aplikacja utworzyła tempa 5GB. w sumie to bez większej różnicy czy jest to temp czy nie, ale ten scenariusz jest bardziej absurdalny i pokazuje nonsens w jaki się wpada, bo plik za chwilę znika. 5GB=4o96oMb. przy teoretycznym 1oo% dostępności, dajmy na to na 5oMb łączu, taki plik repliqje się 4o96o/5o/6o=13,65 minuty. tylko ta jedna zmiana i na naprawdę fajnym łączu i przy 1oo% dostępności – czyli warunki bardzo optymistyczne [czyt. mało realne]. dla 1oMb łącza ta liczba to już ponad 1h.
    co się dzieje w tym czasie? oczywiście uruchamiają się kolejne wyliczenia delty, ponieważ w ciągu tego czasu minęło kilka/wiele 5minutówek. w praktyce może się okazać, że za nim zreplikujemy naszą pierwszą zmianę (5GB) to przestanie ona być aktualna, ponieważ za chwile nadpisze ją kolejna zmiana. czyli w praktyce hv wysyła coś, co za chwilę zostanie nadpisane kolejną zmianą. zamiast się połapać i od razu wysłać ostatnią wersję naszych zmian. mały schemat:

image

jakieś tam obejście to zpauzowanie replikacji i uruchomienie z opcją resynchronizacji [koniecznie run as admin, inaczej krzyczy, że takiej maszyny nie ma]

  • Suspend-VMReplication –vmname <VNAME>
  • Resume-VMReplication –vmname <VNAME> -resynchronize

dzięki opcji resynchronize hv idzie po rozum do głowy i porównuje stan maszyny replikowanej na chwilę obecną z maszyną kopią, ergo tworzy nową deltę jedynie z ostatnimi zmianami. oszczędza nam to replikowanie ‘stanów pośrednich’. niestety resynchronizacja trochę zajmuje, dodatkowo została pisana z myślą o vhd/vhdx nie większych niż 500 GB. jeśli mamy takie trochę większe (np. dysk z danymi baz ponad 1TB), wtedy resynchronizacja zachowuje się mało wydajnie.

pojawia się wiele dodatkowych wątpliwości – bo trzeba nieźle się wstrzelić z czasem tegoż suspendu. w praktyce, wymagane jest małe dochodzenie, w jakich godzinach dochodzi do tworzenia ogromnych delt. osobiście pomogłem sobie małym skryptem, odpalanym ze schedulera co 5 minut

  • $time = "{0:yyyy-MM-dd_HH.mm.ss}" -f (get-date)
  • measure-vmreplication <VNAME> >> c:temp$time.txt

w prosty sposób mamy fajny obraz jak nasze delty rosną na przestrzeni czasu.

a rozwiązanie mogłoby być bardzo trywialne: zamiast nie-wiedzieć-skąd-wymuszone-5-min, wystarczyłoby, aby każda synchronizacja była wzbudzana – ot choćby przez scheduler. dzięki temu można byłoby w pełni kontrolować całą replikację, robić ją np. 2 razy dziennie, omijać okienka maintenancowe i backupowe i tak dalej…

z rzeczy na plus, które faktycznie działają i są miłym zaskoczeniem:

  • kompresja – pogłoski mówiły o superwydajnym rosyjskim algorytmie, ale nie wiadomo jak to jest w praktyce. wiadomo natomiast, że faktycznie działa. zależnie od pomyślności wiatrów skacze od 5o% do 7o%. przy wstępnych wyliczeniach można założyć, że mamy prędkość replikacji równą 1,5 przepustowości naszego łącza.
  • robienie pierwszej repliki na dysk USB – by zacząć replikację, musimy najpierw skopiować całą wirtualną maszynę do lokacji off-site. można to robić po WANie, ale można też tą pierwszą kopię zrobić na nośnik i przesłać go do serwerowni. kiedy nasza ‘initial replica’ zrobi się na dysk USB, po drugiej stronie powstaje replikowana maszyna z pustymi dyskami i snapshotem. Hv replikuje już zmiany do snapshota, mimo, że cała maszyna nie została jeszcze wgrana. replikacja działa, a kiedy kurier zawita do nas z nośnikiem, możemy w dowolnym momencie zaimportować sobie naszą pierwszą replikę.
  • wersjonowanie – czasami może się okazać,
    że replikujemy zmiany z już uszkodzonej wirtualnej maszyny. nasza replika jest odwzorowaniem oryginału 1:1, więc jeśli uszkodzi się OS w oryginalnej maszynie, to samo spotka naszą replikę. wersjonowanie umożliwia trzymanie kilku snapshotów replikowanej maszyny. gdyby okazało się, że coś nie hula, możemy cofnąć się o te kilka/kilkanaście godzin.

na chwilę obecną Hv replica jest i się uśmiecha, ale jest to jeszcze bardzo nieśmiały uśmiech. niemniej działa i przy świadomości ‘charakterystyki’ tego działania, można śmiało wdrożyć to dla klienta, który nie ma wyśrubowanych wymagań. w praktyce eMeS oferuje nam trzy opcje na stworzenia sobie taniego DRP:

  • Hv Replica
  • połączenie Hv Replica i Data Protection Manager Chain Backup – maszyny, których nie da się replikować Hv Replicą, replikujemy DPMem, który podobnie wylicza delty, ale w bardziej zarządzalny sposób.
  • DPM Chain Backp – wszystko replikowane za pomocą DPMa

każde podejście ma swoje zady i walety ale o tym… może kiedyś…

eN & Damian Skrzypiec

export/import maszyn wirtualnych hyper-v

takie proste… ale jak ja do czegoś siadam od razu staje się jakieś takie trudne… należę do grupy opisanej przez paradoks Wittgensteina na temat reguł ograniczonych. należę do tych, dla których najbardziej oczywiste rozwiązania wcale nie są najbardziej oczywiste…

jaki jest problem: nie ma SCVMM i trzeba sobie radzić narzedziami systemowymi. do wyboru mamy: Powershell [yeah!] i hyper-v manager. okazuje się, że export/import z HVmgmt działa zupełnie inaczej niż ten z PS. nie da się wexportować maszyny z GUI a zaimportować z PS – w każdym razie nie w prost. różnice:

GUI PS
EXPORT z GUI export-vm
generuje plik ‘config.xml’ znajdujący się w root katalogu exportu generuje plik <GUID>.xml znajdujący sie w katalogu Virtual Machines
plik xml zawiera tylko kilka podstawowych informacji. plik ma <1Kb plik xml zawiera pełny opis ma 33KB+
IMPORT z GUI import-vm
opcja ‘copy’ zostawia pliki w tym samym miejscu i generuje nowy ID opcja ‘-copy’ kopiuje pliki. standardowo zawsze zachowywany jest oryginalny GUID. aby wygenerować nowy trzeba dodać ‘-generateNewID’.
  nie da się użyć tych samych plików i zostawić GUID. operacja –register –generateNewId generuje błąd. nowy ID wymaga użycia opcji -copy
ładnie zakłda nowy katalog o nazwie maszyny wrzuca pliki do root katalogu maszyn wirtualnych

to tak w skrócie. ciekawostek jest jeszcze kilka – np. jak już się zaimportuje maszynę i przypadkiem zapomni się zmienić GUID to pupa. nie ma [bezpośredniej] mozliwości zmiany GUID – trzeba wywalić i zaimportować jeszcze raz. być może są jakies hardcore’owe możliwości z grzebaniem się w xml’kach ale to na pewno nie jest coś co zrobienia na szybko.

eMeSy chyba próbują zmusić ludzi do korzystania z SCVMM – nawet strona na technecie czy help dla poleceń systemowych hyper-v praktycznie nie istnieje. są parametry ale nie ma opisów jak je stosować i co robią ):

eN.