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

• trochę o v2 providera i różnicach w2k8/w2k12
• nowe klasy WMI w wersji 2o12 R2