Z poprzedniego artykułu wiemy że Azure toleruje tylko maszyny wirtualne uruchamiane z dysków VHD oraz dowiedzieliśmy się jak konwertować inne dyski wirtualne na ten format. W niniejszym wpisie podejmiemy decyzję o odpowiednim przygotowaniu dysku przed wgraniem go do Azure’a oraz w zależności od tego jaki był nasz wybór uruchomimy maszynę wirtualną. UWAGA – mimo że tytuł artykułu sugeruje że poniższe czynności mają zastosowanie tylko przy przenoszeniu maszyny z serwerowni do chmury to nic nie stoi na przeszkodzie by to samo zrobić z maszyną już znajdującą się w chmurze.
Przed wgraniem dysku maszyny wirtualnej do Azure’a musimy podjąć decyzję czy chcemy na niej uruchamiać sysprep, co usunie z niej wszelkie dane specyficzne dla tej konkretnej instalacji, zresetuje status aktywacji systemu, usunie konto administratora lokalnego, itd. Natomiast stan zainstalowanych programów i przechowywanych plików się nie zmieni, więc nasze dane powinny pozostać nietknięte. Jeśli zdecydujemy by nie sysprepować maszyny wtedy przerzucamy maszynę wirtualną wraz z wszelkimi zainstalowanymi sterownikami, informacjami na temat konfiguracji sieci, itp. do Azure’a więc część konfiguracji którą chmura zrobiłaby za nas po pierwszym uruchomieniu maszyny musimy zrobić sami, ale w ten sposób mamy pewność, że maszyna będzie wierną kopią tego co mamy w serwerowni.
Którą opcję wybrać? Decyzję pozostawiam Tobie, ale poniżej wskazówki, które mam nadzieję pomogą w dokonaniu właściwego wyboru:
- Sys-prepować wtedy gdy chcemy z maszyny wirtualnej zrobić szablon dla nowych maszyn tworzonych w chmurze, lub nie obawiamy się że sysprep może coś zepsuć w konfiguracji maszyny lub aplikacji na niej działających. W większości przypadków ta opcja powinna wystarczyć
- Nie sys-prepować wtedy gdy maszyna wirtualna jest skonfigurowana pod konkretne potrzeby i każda zmiana w jej konfiguracji może mieć wpływ na stabilność jej pracy lub pracy aplikacji na niej zainstalowanych. Co prawda w takich przypadkach wątpliwe w ogóle jest czy maszyna będzie prawidłowo działać w chmurze, ale sysprep może dodatkowo więcej napsuć niż pomóc.
Po dokonaniu decyzji jak by ona nie była warto zrobić backup dysku VHD, żeby w razie czego dysponować kopią zapasową jakby coś poszło nie tak.
Dalsze kroki są uzależnione od tego którą metodę wybierzemy. Dla ułatwienia nagłówki będę numerował, jeśli powtórzy się ta sama liczba oznacza to że krok należy wykonać w zależności od tego czy robiliśmy sysprep czy nie. W tytule nagłówka znajduje się informacja której metody dotyczy opis. Do dzieła!
1. Przygotowanie systemu
Od razu zaznaczę, że kroki opisane w tym akapicie nie są konieczne aczkolwiek z pewnością są zalecane. Wykonanie ich wszystkich znacząco zwiększa lub wręcz gwarantuje poprawną pracę maszyny wirtualnej w Azure – szczególnie polecam sprawdzić konfigurację Windows Firewall. Nic tak nie wkurza gdy na koniec próbujemy dostać się do maszyny przez zdalny pulpit i okazuje się, że zapomnieliśmy wyłączyć zaporę. Po aktualny zestaw kroków odsyłam do dokumentacji Azure.
- Uruchom linię komend jako administrator. Wpisz
1route print
Jeśli w sekcji Persistence Routes są jakieś wpisy to usuń je za pomocą komendy route delete. - Usuń proxy
1netsh winhttp reset proxy - Skonfiguruj politykę zarządzania dyskami by wszystkie nowe dyski były automatycznie podłączane
1diskpart san policy=onlineall - Zmień ustawienia czasu w Windows i ustawienia uruchomienia usługi czasu
12REG ADD HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation /v RealTimeIsUniversal /t REG_DWORD /d 1sc config w32time start= auto - Sprawdź czy tryb uruchamiania wszystkich usług Windows jest ustawiony na wartości domyślne. Poniżej lista komend jak to powinno wyglądać
1234567891011121314151617181920212223242526272829303132333435363738394041sc config bfe start= autosc config dcomlaunch start= autosc config dhcp start= autosc config dnscache start= autosc config IKEEXT start= autosc config iphlpsvc start= autosc config PolicyAgent start= demandsc config LSM start= autosc config netlogon start= demandsc config netman start= demandsc config NcaSvc start= demandsc config netprofm start= demandsc config NlaSvc start= autosc config nsi start= autosc config RpcSs start= autosc config RpcEptMapper start= autosc config termService start= demandsc config MpsSvc start= autosc config WinHttpAutoProxySvc start= demandsc config LanmanWorkstation start= autosc config RemoteRegistry start= auto - Usuń wszelkie certyfikaty powiązane z RDP o ile występują
1REG DELETE "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SSLCertificateSHA1Hash” - By wykluczyć timeout’y przy połączeniach RDP zmodyfikuj ustawienia KeepAlive
12345REG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v KeepAliveEnable /t REG_DWORD /d 1 /fREG ADD "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v KeepAliveInterval /t REG_DWORD /d 1 /fREG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp" /v KeepAliveTimeout /t REG_DWORD /d 1 /f - Upewnij się, że usługa RDP jest poprawnie skonfigurowane w kwestii uwierzytelniania
12345REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /fREG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 1 /fREG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fAllowSecProtocolNegotiation /t REG_DWORD /d 1 /f - Upewnij się, że usługa RDP jest włączona
1REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f - Windows Firewall – trzeba dodać wyjątki w Firewallu. Jeśli Windows Firewall jest wyłączony to krok można pominąć.
Inbound:
12345678910111213141516171819netsh advfirewall firewall set rule dir=in name="File and Printer Sharing (Echo Request - ICMPv4-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (LLMNR-UDP-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (NB-Datagram-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (NB-Name-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (Pub-WSD-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (SSDP-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (UPnP-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Network Discovery (WSD EventsSecure-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Windows Remote Management (HTTP-In)" new enable=yesnetsh advfirewall firewall set rule dir=in name="Windows Remote Management (HTTP-In)" new enable=yes
Inbound oraz Outbound
123netsh advfirewall firewall set rule group="Remote Desktop" new enable=yesnetsh advfirewall firewall set rule group="Core Networking" new enable=yes
Outbound
12345678910111213141516171819netsh advfirewall firewall set rule dir=out name="Network Discovery (LLMNR-UDP-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (NB-Datagram-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (NB-Name-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (Pub-WSD-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (SSDP-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (UPnPHost-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (UPnP-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (WSD Events-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (WSD EventsSecure-Out)" new enable=yesnetsh advfirewall firewall set rule dir=out name="Network Discovery (WSD-Out)" new enable=yes - Upewnij się, że WMI jest skonfigurowane poprawnie
1winmgmt /verifyrepository - Upewnij się, że ustawienia BCD są spójne z tymi poniżej
1234567891011bcdedit /set {bootmgr} integrityservices enablebcdedit /set {default} device partition=C:bcdedit /set {default} integrityservices enablebcdedit /set {default} recoveryenabled Offbcdedit /set {default} osdevice partition=C:bcdedit /set {default} bootstatuspolicy IgnoreAllFailures - Sprawdź czy są błędy na dysku
1CHKDSK /f - Upewnij się, że nic nie używa portu 3389, który jest używany przez Azure do połączeń RDP
1netstat -anob - Upewnij się, że do maszyny można połączyć się przez RDP z wykorzystaniem konta lokalnego administratora
- Włącz zbieranie logów
123456789REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 2 /f`REG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "c:\CrashDumps" /fREG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount /t REG_DWORD /d 10 /fREG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /fsc config wer start= auto - W Powershell wykonaj komendę włączającą WinRM
1Enable-PSRemoting -force - Zainstaluj Azure Virtual Machines Agent
- Zainstaluj aktualizacje!
2. Sysprep: przygotowanie maszyny do przeniesienia do Azure
Na początku musimy uruchomić sysprep na maszynie wirtualnej którą będziemy przenosić do Azure. W tym celu logujemy się na serwer, uruchamiany linię komend jako administrator i wpisujemy
1 2 3 |
cd %windir%\system32\sysprep sysprep.exe |
W okienku, które się pojawi zaznaczamy Generalize i wybieramy Shutdown
Po kliknięciu OK rozpocznie się proces generalizacji systemu, a po jego zakończeniu serwer zostanie wyłączony. Od teraz nie możemy się na niego dostać zdalnym pulpitem, a po ponownym uruchomieniu zostaniemy powitani przez kreator jak przy nowej instalacji Windows Server (trzeba między innymi podać poświadczenia administratora).
2. Nie-sysprep: przygotowanie maszyny do przeniesienia do Azure
Przygotowanie systemu w tej metodzie sprowadza się do włączenia możliwości połączeń zdalnych (RDP) oraz usunięciu ustawień sieciowych. Maszyna musi dostawać ustawienia z DHCP żeby działała poprawnie w Azure. Następnie instalujemy Azure Virtual Machines Agent. Na koniec warto włączyć zbieranie logów – w razie jakby z maszyną działo się coś złego to z poziomu portalu Azure będziemy mogli to sprawdzić.
1 2 3 4 5 6 7 8 9 |
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t REG_DWORD /d 2 /f` REG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "c:\CrashDumps" /f REG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount /t REG_DWORD /d 10 /f REG ADD "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f sc config wer start= auto |
3. Wgranie dysku VHD do Azure
Teraz uruchamiamy Powershell, najlepiej jako administrator i logujemy się do Azure’a
1 2 3 |
Login-AzureRmAccount Select-AzureRMSubscription -SubscriptionName "nazwa_subskrypcji" |
nazwa_subskrypcji to oczywiście nazwa subskrypcji w której znajduje się konto magazynu do którego będziemy wgrywać dysk za pomocą poniższej komendy, ewentualnie można też wykorzystać AzCopy
1 |
Add-AzureRmVhd -ResourceGroupName "nazwa_grupy_zasobów" -Destination "https://konto_magazynu/kontener/blob.vhd" -LocalFilePath "ścieżka_do_pliku_vhd" |
Przykład:
Add-AzureRmVhd -ResourceGroupName „VHDvmRG” -Destination „https://vhdvm.blob.core.windows.net/vhds/vhdvm.vhd” -LocalFilePath „C:\Users\ttuczapski\Documents\vhdVM.vhd”
Chwilę się zejdzie zanim wgrywanie pliku się zakończy, oczywiście to jak długo będziemy czekać zależy od tego jak dużo waży plik i jakim łączem dysponujemy. Proces wgrywania powinien zakończyć się komunikatem w stylu
1 2 3 4 5 |
Elapsed time for upload: 00:22:45 LocalFilePath DestinationUri ------------- -------------- C:\Users\ttuczapski\Documents\vhdVM.vhd https://vhdvm.blob.core.windows.net/vh... |
4. Sysprep: utworzenie maszyny wirtualnej
Utworzenie maszyny zaczniemy od stworzenia sieci i jej konfiguracji. Oczywiście możesz skorzystać z już istniejącej wirtualnej infrastruktury ale przyjmuję że tworzę wszystko od zera.
1 2 3 |
$rg = "nazwa_grupy_zasobów" $location = "lokacja" $subnet = New-AzureRmVirtualNetworkSubnetConfig -Name "nazwa_subnetu" -AddressPrefix 0.0.0.0/0 |
$rg – jeśli chodzi o grupę zasobów to wszędzie używam tej samej grupy zasobów w której jest wgrany wcześniej dysk – takie jest wymaganie
$location – nazwa lokacji centrum danych Azure np. „West Europe”
Jako AddressPrefix należy podać przestrzeń adresową podsieci. Najlepiej sprawdzić w Azure jakie są przestrzenie już istniejących podsieci i wybrać taki sam lub jakiś podobny.
Teraz tworzymy zasób sieci wirtualnej
1 |
$vnet = New-AzureRmVirtualNetwork -Name "nazwa_sieci" -ResourceGroupName $rg -Location $location -AddressPrefix 0.0.0.0/0 -Subnet $subnet |
AddressPrefix można podać taki sam jak przy wykonywaniu wcześniejszej komendy. założenie jest takie że $subnet powinien mieć mniejszą pulę adresów niż $vnet np.:
$subnet = 10.2.0.0/24
$vnet = 10.2.0.0/16
U mnie to wyglądało następująco:
$rg = „vhdvmRG”
$location = „West Europe”
$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name „vhdvmSubnet” -AddressPrefix 10.12.0.0/16
$vnet = New-AzureRmVirtualNetwork -Name „vhdvmNetwork” -ResourceGroupName $rg -Location $location -AddressPrefix 10.12.0.0/16 -Subnet $subnet
Teraz w grupie zasobów powinien pojawić się nowy zasób sieci wirtualnej. A mając sieć wirtualną możemy stworzyć publiczny adres IP i kartę sieciową dla naszej maszyny.
1 2 3 |
$pip = New-AzureRmPublicIpAddress -Name "vhdvmpip" -ResourceGroupName $rg -Location $location -AllocationMethod Dynamic $nic = New-AzureRmNetworkInterface -Name "vhdvmNic" -ResourceGroupName $rg -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id |
Oczywiście nazwy zasobów możesz zastąpić własnymi wartościami. Kolejne dwa zasoby powinny pojawić się w danej grupie zasobów.
Mając podwaliny pod infrastrukturę sieciową możemy w końcu utworzyć maszynę wirtualną
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
$cred = Get-Credential #dane do logowania do maszyny na konto administratora $storageAcc = Get-AzureRmStorageAccount -ResourceGroupName $rg -AccountName "vhdvmsa" #konto magazynu w którym znajduje się wgrany dysk $vmConfig = New-AzureRmVMConfig -VMName "VHDvm" -VMSize "Standard_DS2" #nazwa i rozmiar maszyny wirtualnej $vm = Set-AzureRmVMOperatingSystem -VM $vmConfig -Windows -ComputerName "VHDvm" -Credential $cred -ProvisionVMAgent -EnableAutoUpdate #wstępna konfiguracja maszyny wirtualnej $vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id #podłączenie karty sieciowej $osDiskUri = '{0}vhds/{1}-{2}.vhd' -f $storageAcc.PrimaryEndpoints.Blob.ToString(), "VHDvm", "vhdvm.vhd" #URI wgranego dysku $vm = Set-AzureRmVMOSDisk -VM $vm -Name "vhdvm.vhd" -VhdUri $osDiskUri -CreateOption fromImage -SourceImageUri "https://vhdvm.blob.core.windows.net/vhds/vhdvm.vhd" -Windows #ustawienie wgranego dysku jako dysk z obrazem systemu i utworzenie jego kopii jako dysk systemowy tworzonej maszyny New-AzureRmVM -ResourceGroupName $rg -Location $location -VM $vm #utworzenie maszyny wirtualnej o powyższej konfiguracji |
Utworzenie maszyny wirtualnej powinno zostać potwierdzone komunikatem
1 2 3 |
RequestId IsSuccessStatusCode StatusCode ReasonPhrase --------- ------------------- ---------- ------------ True OK OK |
Teraz po zalogowaniu się do portalu Azure powinna być widoczna utworzona maszyna wirtualna. W ramach testu podłączyłem się do niej i okazało się że baza danych znajduje się tam gdzie powinna i w dodatku jest online 🙂 Wszystkie pliki (oprócz tych w folderze użytkownika – są one usuwane przez sysprep) były na swoim miejscu. Reasumując – na pierwszy rzut oka wygląda na to że przeniesienie maszyny wirtualnej z serwerowni do Azure nic nie pogubiło 🙂
5. Nie-sysprep: utworzenie maszyny wirtualnej
Tworzenie maszyny wirtualnej w Azure z dysku z systemem który nie został potraktowany sysprepem, robi się analogicznie jak w przypadku maszyny sysprepowanej z tą różnicą że w Powershell przy ustawianiu dysku OS maszyny należy podać opcję „Attach” zamiast „fromImage„. Dla nas ma to takie dodatkowe znaczenie że taki dysk można użyć a dokładniej podłączyć tylko do jednej maszyny naraz. Natomiast w przypadku opcji „fromImage” dysk bazowy jest klonowany i dopiero z klonu powstaje dysk systemowy. W ten sposób dysk bazowy można wykorzystać wiele razy do tworzenia nowych maszyn wirtualnych.
Utworzenie maszyny zaczniemy od stworzenia sieci i jej konfiguracji. Oczywiście możesz skorzystać z już istniejącej wirtualnej infrastruktury ale przyjmuję że tworzę wszystko od zera.
1 2 3 |
$rg = "nazwa_grupy_zasobów" $location = "lokacja" $subnet = New-AzureRmVirtualNetworkSubnetConfig -Name "nazwa_subnetu" -AddressPrefix 0.0.0.0/0 |
$rg – jeśli chodzi o grupę zasobów to wszędzie używam tej samej grupy zasobów w której jest wgrany wcześniej dysk – takie jest wymaganie
$location – nazwa lokacji centrum danych Azure np. „West Europe”
Jako AddressPrefix należy podać przestrzeń adresową podsieci. Najlepiej sprawdzić w Azure jakie są przestrzenie już istniejących podsieci i wybrać taki sam lub jakiś podobny.
Teraz tworzymy zasób sieci wirtualnej
1 |
$vnet = New-AzureRmVirtualNetwork -Name "nazwa_sieci" -ResourceGroupName $rg -Location $location -AddressPrefix 0.0.0.0/0 -Subnet $subnet |
AddressPrefix można podać taki sam jak przy wykonywaniu wcześniejszej komendy. założenie jest takie że $subnet powinien mieć mniejszą pulę adresów niż $vnet np.:
$subnet = 10.2.0.0/24
$vnet = 10.2.0.0/16
U mnie to wyglądało następująco:
$rg = „vhdvmRG”
$location = „West Europe”
$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name „vhdvmSubnet” -AddressPrefix 10.12.0.0/16
$vnet = New-AzureRmVirtualNetwork -Name „vhdvmNetwork” -ResourceGroupName $rg -Location $location -AddressPrefix 10.12.0.0/16 -Subnet $subnet
Teraz w grupie zasobów powinien pojawić się nowy zasób sieci wirtualnej. A mając sieć wirtualną możemy stworzyć publiczny adres IP i kartę sieciową dla naszej maszyny.
1 2 3 |
$pip = New-AzureRmPublicIpAddress -Name "vhdvmpip" -ResourceGroupName $rg -Location $location -AllocationMethod Dynamic $nic = New-AzureRmNetworkInterface -Name "vhdvmNic" -ResourceGroupName $rg -Location $location -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id |
Oczywiście nazwy zasobów możesz zastąpić własnymi wartościami. Kolejne dwa zasoby powinny pojawić się w danej grupie zasobów.
Mając podwaliny pod infrastrukturę sieciową możemy w końcu utworzyć maszynę wirtualną
1 2 3 4 5 6 7 8 9 10 11 |
$storageAcc = Get-AzureRmStorageAccount -ResourceGroupName $rg -AccountName "vhdvmsa" #konto magazynu w którym znajduje się wgrany dysk $osDiskUri = '{0}vhds/{1}-{2}.vhd' -f $storageAcc.PrimaryEndpoints.Blob.ToString(), "VHDvm", "vhdvm.vhd" #URI wgranego dysku $VM = New-AzureRmVMConfig -VMName "vhdvmspec" -VMSize "Standard_DS2" #nazwa i rozmiar maszyny wirtualnej $VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $nic.Id #podłączenie karty sieciowej $VM = Set-AzureRmVMOSDisk -VM $VM -Name "vhdvm.vhd" -VhdUri $osDiskUri -CreateOption Attach -Windows #ustawienie wgranego dysku jako dysk systemowy tworzonej maszyny New-AzureRmVM -ResourceGroupName $rg -Location $location -VM $VM #utworzenie maszyny wirtualnej o powyższej konfiguracji |
Utworzenie maszyny wirtualnej powinno zostać potwierdzone komunikatem
1 2 3 |
RequestId IsSuccessStatusCode StatusCode ReasonPhrase --------- ------------------- ---------- ------------ True OK OK |
Teraz po zalogowaniu się do portalu Azure powinna być widoczna utworzona maszyna wirtualna. W ramach testu podłączyłem się do niej używając tych samych poświadczeń jakich używałem logując się on premise. Okazało się że baza danych znajduje się tam gdzie powinna i w dodatku jest online 🙂 Wszystkie pliki były na swoim miejscu. Reasumując – na pierwszy rzut oka wygląda na to że przeniesienie maszyny wirtualnej z serwerowni do Azure nic nie pogubiło i w dodatku nie trzeba było jej traktować sysprepem co oznacza że cały czas można działać z jednym dyskiem vhd bez konieczności tworzenia z niego obrazu.
5. Nie-sysprep: po utworzeniu maszyny w Azure
Na maszynie, która nie została przygotowana sysprepem trzeba jeszcze ustawić plik stronicowania na tymczasowym dysku D, tak jak ma to miejsce gdy tworzymy nową maszynę z obrazu dostępnych w Azure:
1 |
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /t REG_MULTI_SZ /v PagingFiles /d "D:\pagefile.sys 0 0" /f |
I to by było na tyle, teraz możesz przerzucać maszyny wirtualne między chmurą a lokalnym serwerem w celu np. optymalizacji obciążeń lub ograniczenia kosztów 🙂
To czego brakuje a co na pewno warto skonfigurować to Network Security Group (NSG) – bez niej cały ruch z i do internetu jest przepuszczany przez maszynę wirtualną co może powodować poważne zagrożenie bezpieczeństwa. Możesz dodać NSG na własną rękę (jest taka możliwość zarówno z poziomu portalu jak i Powershell) lub poczekać na następny wpis, w którym opiszę to zagadnienie 🙂