Migrowanie do usługi Azure Stack HCI na nowym sprzęcie
Dotyczy: Azure Stack HCI, wersje 22H2 i 21H2; Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2008 R2
W tym temacie opisano sposób migrowania plików maszyn wirtualnych na Windows Server 2012 R2, Windows Server 2016 lub Windows Server 2019 do nowego sprzętu serwera usługi Azure Stack HCI przy użyciu Windows PowerShell i narzędzia Robocopy. Robocopy to niezawodna metoda kopiowania plików z jednego serwera na inny. Wznawia działanie po odłączeniu i kontynuuje pracę od ostatniego znanego stanu. Program Robocopy obsługuje również wielowątkowe kopiowanie plików za pośrednictwem bloku komunikatów serwera (SMB). Aby uzyskać więcej informacji, zobacz Robocopy.
Uwaga
Migracja na żywo funkcji Hyper-V i replika funkcji Hyper-V z systemu Windows Server do usługi Azure Stack HCI nie jest obsługiwana. Jednak replika funkcji Hyper-V jest prawidłowa i obsługiwana między systemami HCI. Nie można replikować maszyny wirtualnej do innego woluminu w tym samym klastrze tylko do innego systemu HCI.
Jeśli masz maszyny wirtualne w systemie Windows 2012 R2 lub starszym, które chcesz przeprowadzić migrację, zobacz Migrowanie starszych maszyn wirtualnych.
Aby przeprowadzić migrację do usługi Azure Stack HCI przy użyciu tego samego sprzętu, zobacz Migrowanie do usługi Azure Stack HCI na tym samym sprzęcie.
Na poniższym diagramie przedstawiono klaster źródłowy systemu Windows Server i klaster docelowy usługi Azure Stack HCI jako przykład. Maszyny wirtualne można również migrować na autonomicznych serwerach.
Jeśli chodzi o oczekiwany przestój, korzystanie z jednej karty sieciowej z podwójną siecią RDMA o pojemności 40 GB East-West między klastrami i Robocopy skonfigurowanym na potrzeby 32 wielowątków, można zrealizować szybkość transferu 1,9 TB na godzinę.
Uwaga
Migrowanie maszyn wirtualnych dla klastrów rozproszonych nie zostało omówione w tym artykule.
Zanim rozpoczniesz
Przed rozpoczęciem migracji należy wziąć pod uwagę kilka wymagań i kwestii:
Wszystkie polecenia Windows PowerShell muszą być uruchamiane jako administrator.
Musisz mieć poświadczenia domeny z uprawnieniami administratora zarówno dla klastrów źródłowych, jak i docelowych, z pełnymi uprawnieniami do źródłowej i docelowej jednostki organizacyjnej zawierającej oba klastry.
Oba klastry muszą znajdować się w tym samym lesie usługi Active Directory i domenie, aby ułatwić uwierzytelnianie Kerberos między klastrami na potrzeby migracji maszyn wirtualnych.
Oba klastry muszą znajdować się w jednostkach organizacyjnych usługi Active Directory z zasady grupy Object (GPO) Blokuj dziedziczenie ustawione na tej jednostki organizacyjnej. Gwarantuje to, że żadne obiekty zasad grupy na poziomie domeny i zasady zabezpieczeń nie mogą mieć wpływu na migrację.
Oba klastry muszą być połączone z tym samym źródłem czasu, aby obsługiwać spójne uwierzytelnianie Kerberos między klastrami.
Zanotuj nazwę przełącznika wirtualnego funkcji Hyper-V używaną przez maszyny wirtualne w klastrze źródłowym. Przed zaimportowaniem maszyn wirtualnych należy użyć tej samej nazwy przełącznika wirtualnego dla klastra docelowego usługi Azure Stack HCI "sieć maszyn wirtualnych".
Usuń wszystkie pliki obrazów ISO dla źródłowych maszyn wirtualnych. Odbywa się to przy użyciu Menedżera funkcji Hyper-V we właściwościach maszyny wirtualnej w sekcji Sprzęt. Wybierz pozycję Usuń dla dowolnych wirtualnych dysków CD/DVD.
Zamknij wszystkie maszyny wirtualne w klastrze źródłowym. Jest to wymagane w celu zapewnienia, że kontrola wersji i stan są utrzymywane w całym procesie migracji.
Sprawdź, czy usługa Azure Stack HCI obsługuje twoją wersję maszyn wirtualnych do importowania i aktualizowania maszyn wirtualnych zgodnie z potrzebami. Zobacz sekcję Pomocy technicznej i aktualizacji wersji maszyny wirtualnej , aby dowiedzieć się, jak to zrobić.
Tworzenie kopii zapasowej wszystkich maszyn wirtualnych w klastrze źródłowym. Wykonaj spójną na poziomie awarii kopię zapasową wszystkich aplikacji i danych oraz spójną na poziomie aplikacji kopię zapasową wszystkich baz danych. Aby utworzyć kopię zapasową na platformie Azure, zobacz Use Azure Backup (Korzystanie z Azure Backup).
Utwórz punkt kontrolny maszyn wirtualnych klastra źródłowego i kontrolera domeny w przypadku konieczności wycofania się z poprzedniego stanu. Nie dotyczy to serwerów fizycznych.
Upewnij się, że maksymalne rozmiary ramek Jumbo są takie same między sieciami magazynu źródłowego i docelowego klastra, w szczególności kartami sieciowymi RDMA i odpowiednimi portami sieciowymi przełącznika, aby zapewnić najbardziej wydajny rozmiar pakietów transferu kompleksowego.
Zanotuj nazwę przełącznika wirtualnego funkcji Hyper-V w klastrze źródłowym. Użyjesz go ponownie w klastrze docelowym.
Sprzęt azure Stack HCI powinien mieć co najmniej taką samą pojemność i konfigurację jak sprzęt źródłowy.
Zminimalizuj liczbę przeskoków sieciowych lub odległość fizyczną między klastrami źródłowymi i docelowymi, aby ułatwić najszybszy transfer plików.
Obsługa i aktualizacja wersji maszyny wirtualnej
W tej tabeli wymieniono wersje systemu operacyjnego Windows Server i ich wersje maszyn wirtualnych.
Niezależnie od wersji systemu operacyjnego, na którym może być uruchomiona maszyna wirtualna, minimalna wersja maszyny wirtualnej obsługiwana na potrzeby bezpośredniej migracji do usługi Azure Stack HCI to wersja 5.0. Reprezentuje to domyślną wersję maszyn wirtualnych w Windows Server 2012 R2. Dlatego przed migracją wszystkie maszyny wirtualne działające w wersji 2.0, 3.0 lub 4.0 muszą zostać zaktualizowane do wersji 5.0.
| Wersja systemu operacyjnego | Wersja maszyny wirtualnej |
|---|---|
| Windows Server 2008 SP1 | 2.0 |
| Windows Server 2008 z dodatkiem R2 | 3.0 |
| Windows Server 2012 | 4,0 |
| Windows Server 2012 z dodatkiem R2 | 5.0 |
| Windows Server 2016 | 8.0 |
| Windows Server 2019 | 9.0 |
| Azure Stack HCI | 9.0 |
W przypadku maszyn wirtualnych w systemie Windows Server 2012 R2, Windows Server 2016 i Windows Server 2019 zaktualizuj wszystkie maszyny wirtualne do najnowszej wersji maszyny wirtualnej obsługiwanej na sprzęcie źródłowym przed uruchomieniem skryptu migracji narzędzia Robocopy. Gwarantuje to, że wszystkie maszyny wirtualne są co najmniej w wersji 5.0 w celu pomyślnego zaimportowania maszyny wirtualnej.
W przypadku maszyn wirtualnych w systemie Windows Server 2008 z dodatkiem SP1, Windows Server 2008 R2-SP1 i Windows 2012 wersja maszyny wirtualnej będzie mniejsza niż wersja 5.0. Te maszyny wirtualne używają również pliku .xml do konfiguracji zamiast pliku vcmx. W związku z tym bezpośredni import maszyny wirtualnej do usługi Azure Stack HCI nie jest obsługiwany. W takich przypadkach dostępne są dwie opcje, zgodnie z opisem w temacie Migrowanie starszych maszyn wirtualnych.
Aktualizowanie wersji maszyny wirtualnej
Następujące polecenia dotyczą Windows Server 2012 R2 i nowszych. Użyj następującego polecenia, aby wyświetlić wszystkie wersje maszyn wirtualnych na jednym serwerze:
Get-VM * | Format-Table Name,Version
Aby wyświetlić wszystkie wersje maszyn wirtualnych na wszystkich serwerach w klastrze:
Get-VM –ComputerName (Get-ClusterNode)
Aby zaktualizować wszystkie maszyny wirtualne do najnowszej obsługiwanej wersji na wszystkich serwerach:
Get-VM –ComputerName (Get-ClusterNode) | Update-VMVersion -Force
Zalecenia RDMA
Jeśli używasz zdalnego bezpośredniego dostępu do pamięci (RDMA), robocopy może wykorzystać go do kopiowania maszyn wirtualnych między klastrami. Poniżej przedstawiono kilka zaleceń dotyczących korzystania z funkcji RDMA:
Połącz oba klastry z tym samym przełącznikiem stojaka (ToR), aby użyć najszybszej ścieżki sieciowej między klastrami źródłowymi i docelowymi. W przypadku ścieżki sieciowej magazynu zwykle obsługuje 10 GbE/25 GbE lub wyższą szybkość i wykorzystuje funkcję RDMA.
Jeśli karta RDMA lub standard różni się między klastrami źródłowymi i docelowymi (ROCE vs iWARP), Narzędzie Robocopy zamiast tego będzie korzystać z protokołu SMB za pośrednictwem protokołu TCP/IP za pośrednictwem najszybszej dostępnej sieci. Zazwyczaj będzie to podwójne 10 Gbe/25 Gbe lub większa szybkość sieci East-West, zapewniając najbardziej optymalny sposób kopiowania plików VHDX maszyny wirtualnej między klastrami.
Aby upewnić się, że narzędzie Robocopy może korzystać z funkcji RDMA między klastrami (siecią wschodnio-zachodnią), skonfiguruj sieci magazynu RDMA, aby można było je kierować między klastrami źródłowymi i docelowymi.
Tworzenie nowego klastra
Przed utworzeniem klastra usługi Azure Stack HCI należy zainstalować system operacyjny Azure Stack HCI na każdym nowym serwerze, który będzie znajdować się w klastrze. Aby uzyskać informacje o tym, jak to zrobić, zobacz Deploy the Azure Stack HCI operating system (Wdrażanie systemu operacyjnego Azure Stack HCI).
Utwórz nowy klaster za pomocą Windows Admin Center lub Windows PowerShell. Aby uzyskać szczegółowe informacje na temat tego sposobu, zobacz Tworzenie klastra usługi Azure Stack HCI przy użyciu Windows Admin Center i Tworzenie klastra usługi Azure Stack HCI przy użyciuWindows PowerShell.
Ważne
Nazwy przełącznika wirtualnego funkcji Hyper-V (VMSwitch) między klastrami muszą być takie same. Upewnij się, że nazwy przełączników wirtualnych utworzone w klastrze docelowym są zgodne z nazwami używanymi w klastrze źródłowym na wszystkich serwerach. Przed zaimportowaniu maszyn wirtualnych sprawdź nazwy przełączników dla tego samego.
Uwaga
Aby można było utworzyć nowe maszyny wirtualne, należy zarejestrować klaster usługi Azure Stack HCI na platformie Azure. Aby uzyskać więcej informacji, zobacz Rejestrowanie za pomocą platformy Azure.
Uruchamianie skryptu migracji
Poniższy skrypt Robocopy_Remote_Server_.ps1 programu PowerShell używa narzędzia Robocopy do kopiowania plików maszyn wirtualnych oraz ich zależnych katalogów i metadanych ze źródła do klastra docelowego. Ten skrypt został zmodyfikowany z oryginalnego skryptu w witrynie TechNet pod adresem: Robocopy Files to Remote Server Using PowerShell and RoboCopy (Pliki robocopy do serwera zdalnego przy użyciu programu PowerShell i narzędzia RoboCopy).
Skrypt kopiuje wszystkie pliki VHD, VHDX i VMCX do klastra docelowego dla danego udostępnionego woluminu klastra (CSV). Jeden plik CSV jest migrowany naraz.
Skrypt migracji jest uruchamiany lokalnie na każdym serwerze źródłowym, aby korzystać z zalet funkcji RDMA i szybkiego transferu sieciowego. W tym celu:
Upewnij się, że każdy docelowy węzeł klastra jest ustawiony na właściciela woluminu CSV dla docelowego woluminu CSV.
Aby określić lokalizację wszystkich plików VHD i VHDX maszyny wirtualnej do skopiowania, użyj następującego polecenia cmdlet. Przejrzyj plik,
C:\vmpaths.txtaby określić najbardziej górną ścieżkę pliku źródłowego dla narzędzia Robocopy, aby rozpocząć od kroku 4:Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txtUwaga
Jeśli pliki VHD i VHDX znajdują się w różnych ścieżkach na tym samym woluminie, należy uruchomić skrypt migracji dla każdej innej ścieżki, aby skopiować je wszystkie.
Zmień następujące trzy zmienne, aby pasować do ścieżki źródłowej maszyny wirtualnej klastra z docelową ścieżką maszyny wirtualnej klastra:
$Dest_Server = "Node01"$source = "C:\Clusterstorage\Volume01"$dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
Uruchom następujący skrypt na każdym serwerze źródłowym systemu Windows Server:
<#
#===========================================================================
# Script: Robocopy_Remote_Server_.ps1
#===========================================================================
.DESCRIPTION:
Change the following variables to match your source cluster VM path with the destination cluster VM path. Then run this script on each source Cluster Node CSV owner and make sure the destination cluster node is set to the CSV owner for the destination CSV.
Change $Dest_Server = "Node01"
Change $source = "C:\Clusterstorage\Volume01"
Change $dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
#>
$Space = Write-host ""
$Dest_Server = "Node01"
$source = "C:\Clusterstorage\Volume01"
$dest = "\\$Dest_Server\C$\Clusterstorage\Volume01"
$Logfile = "c:\temp\Robocopy1-$date.txt"
$date = Get-Date -UFormat "%Y%m%d"
$cmdArgs = @("$source","$dest",$what,$options)
$what = @("/COPYALL")
$options = @("/E","/MT:32","/R:0","/W:1","/NFL","/NDL","/LOG:$logfile","/xf")
## Get Start Time
$startDTM = (Get-Date)
$Dest_Server = "Node01"
$TARGETDIR = \\$Dest_Server\C$\Clusterstorage\Volume01
$Space
Clear
## Provide Information
Write-host ".....Copying Virtual Machines FROM $Source to $TARGETDIR ....................." -fore Green -back black
Write-Host "........................................." -Fore Green
## Kick off the copy with options defined
robocopy @cmdArgs
## Get End Time
$endDTM = (Get-Date)
## Echo Time elapsed
$Time = "Elapsed Time: = $(($endDTM-$startDTM).totalminutes) minutes"
## Provide time it took
Write-host ""
Write-host " Copy Virtual Machines to $Dest_Server has been completed......" -fore Green -back black
Write-host " Copy Virtual Machines to $Dest_Server took $Time ......" -fore Cyan
Importowanie maszyn wirtualnych
Najlepszym rozwiązaniem jest utworzenie co najmniej jednego udostępnionego woluminu klastra (CSV) na węzeł klastra, aby umożliwić równomierne równoważenie maszyn wirtualnych dla każdego właściciela woluminu CSV w celu zwiększenia odporności, wydajności i skali obciążeń maszyn wirtualnych. Domyślnie to saldo odbywa się automatycznie co pięć minut i należy je wziąć pod uwagę podczas korzystania z narzędzia Robocopy między węzłem klastra źródłowego a docelowym węzłem klastra, aby upewnić się, że właściciele źródłowych i docelowych woluminów CSV są zgodni, aby zapewnić najbardziej optymalną ścieżkę transferu i szybkość.
Wykonaj następujące kroki w klastrze rozwiązania Azure Stack HCI, aby zaimportować maszyny wirtualne, udostępnić je w wysokiej dostępności i uruchomić je:
Uruchom następujące polecenie cmdlet, aby wyświetlić wszystkie węzły właściciela woluminu CSV:
Get-ClusterSharedVolumeDla każdego węzła serwera przejdź do
C:\Clusterstorage\Volumei ustaw ścieżkę dla wszystkich maszyn wirtualnych — na przykładC:\Clusterstorage\volume01.Uruchom następujące polecenie cmdlet w każdym węźle właściciela woluminu CSV, aby wyświetlić ścieżkę do wszystkich plików VMCX na wolumin przed zaimportowaniem maszyny wirtualnej. Zmodyfikuj ścieżkę tak, aby odpowiadała twojemu środowisku:
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -RecurseUwaga
Windows Server 2012 R2 i starszych maszyn wirtualnych używają pliku XML zamiast pliku VCMX. Aby uzyskać więcej informacji, zobacz sekcję Migrowanie starszych maszyn wirtualnych.
Uruchom następujące polecenie cmdlet dla każdego węzła serwera, aby zaimportować, zarejestrować i udostępnić maszyny wirtualne o wysokiej dostępności w każdym węźle właściciela woluminu CSV. Zapewnia to równomierną dystrybucję maszyn wirtualnych w celu uzyskania optymalnej alokacji procesora i pamięci:
Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vmcx" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRoleUruchom każdą docelową maszynę wirtualną w każdym węźle:
Start-VM -NameZaloguj się i sprawdź, czy wszystkie maszyny wirtualne są uruchomione i czy są tam wszystkie twoje aplikacje i dane:
Get-VM -ComputerName Server01 | Where-Object {$_.State -eq 'Running'}Zaktualizuj maszyny wirtualne do najnowszej wersji rozwiązania Azure Stack HCI, aby wykorzystać wszystkie postępy:
Get-VM | Update-VMVersion -ForcePo zakończeniu działania skryptu sprawdź plik dziennika robocopy pod kątem błędów wymienionych i sprawdź, czy wszystkie maszyny wirtualne zostały pomyślnie skopiowane.
Migrowanie starszych maszyn wirtualnych
Jeśli masz maszyny wirtualne z systemem Windows Server 2008 z dodatkiem SP1, Windows Server 2008 R2-SP1, Windows Server 2012 lub Windows Server 2012 R2, ta sekcja dotyczy Użytkownika. Dostępne są dwie opcje obsługi tych maszyn wirtualnych:
Najpierw przeprowadź migrację tych maszyn wirtualnych do Windows Server 2012 R2, Windows Server 2016 lub Windows Server 2019, zaktualizuj wersję maszyny wirtualnej, a następnie rozpocznij proces migracji.
Użyj narzędzia Robocopy, aby skopiować wszystkie wirtualne dyski twarde maszyn wirtualnych do usługi Azure Stack HCI. Następnie utwórz nowe maszyny wirtualne i dołącz skopiowane wirtualne dyski twarde do maszyn wirtualnych w usłudze Azure Stack HCI. Spowoduje to obejście ograniczenia wersji maszyny wirtualnej dla tych starszych maszyn wirtualnych.
Windows Server 2012 R2 i starszych hostów funkcji Hyper-V używają formatu pliku XML dla konfiguracji maszyny wirtualnej, który różni się od formatu pliku VCMX używanego dla hostów Windows Server 2016 i nowszych funkcji Hyper-V. Wymaga to innego polecenia narzędzia Robocopy, aby skopiować te maszyny wirtualne do usługi Azure Stack HCI.
Opcja 1. Migracja etapowa
Jest to migracja dwuetapowa używana dla maszyn wirtualnych hostowanych w systemie Windows Server 2008 z dodatkiem SP1, Windows Server 2008 R2-SP i Windows Server 2012. Oto proces, którego używasz:
Znajdź lokalizację wszystkich plików VHD i VHDX maszyny wirtualnej do skopiowania, a następnie przejrzyj
vmpaths.txtplik, aby określić najbardziej górną ścieżkę pliku źródłowego narzędzia Robocopy do rozpoczęcia od. Użyj następującego polecenia cmdlet:Get-ChildItem -Path "C:\Clusterstorage\Volume01\*.vhd*" -Recurse > c:\vmpaths.txtUżyj następującego przykładowego polecenia narzędzia Robocopy, aby skopiować maszyny wirtualne do Windows Server 2012 R2 najpierw przy użyciu najbardziej najwyższej ścieżki określonej w kroku 1:
Robocopy \\2012R2-Clus01\c$\clusterstorage\volume01\Hyper-V\ \\20H2-Clus01\c$\clusterstorage\volume01\Hyper-V\ /E /MT:32 /R:0 /w:1 /NFL /NDL /copyall /log:c:\log.txt /xfSprawdź, czy nazwa przełącznika wirtualnego (
VMSwitch) używana w klastrze Windows Server 2012 R2 jest taka sama jak nazwa przełącznika używana w źródle systemu Windows 2008 R2 lub Windows Server 2008 R2-SP1. Aby wyświetlić nazwy przełączników używane na wszystkich serwerach w klastrze, użyj następującego polecenia:Get-VMSwitch -CimSession $Servers | Select-Object NameZmień nazwę przełącznika w systemie Windows Server 20212 R2 zgodnie z potrzebami. Aby zmienić nazwę przełącznika na wszystkich serwerach w klastrze, użyj następującego polecenia:
Invoke-Command -ComputerName $Servers -ScriptBlock {rename-VMSwitch -Name $using:vSwitcholdName -NewName $using:vSwitchnewname}Skopiuj i zaimportuj maszyny wirtualne do Windows Server 2012 R2:
Get-ChildItem -Path "c:\clusterstorage\volume01\Hyper-V\*.xml"-RecurseGet-ChildItem -Path "c:\clusterstorage\volume01\image\*.xml" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRoleW Windows Server 2012 R2 zaktualizuj maszynę wirtualną do wersji 5.0 dla wszystkich maszyn wirtualnych:
Get-VM | Update-VMVersion -ForceUruchom skrypt migracji, aby skopiować maszyny wirtualne do rozwiązania Azure Stack HCI.
Postępuj zgodnie z procesem w sekcji Importowanie maszyn wirtualnych, zastępując kroki 3 i Krok 4 następującymi elementami, aby obsłużyć pliki XML i zaimportować maszyny wirtualne do usługi Azure Stack HCI:
Get-ChildItem -Path "c:\clusterstorage\volume01\Hyper-V\*.xml"-RecurseGet-ChildItem -Path "c:\clusterstorage\volume01\image\*.xml" -Recurse | Import-VM -Register | Get-VM | Add-ClusterVirtualMachineRoleWykonaj pozostałe kroki opisane w temacie Importowanie maszyn wirtualnych.
Opcja 2. Bezpośrednie kopiowanie wirtualnego dysku twardego
Ta metoda używa narzędzia Robocopy do kopiowania wirtualnych dysków twardych maszyn wirtualnych hostowanych w systemie Windows 2008 z dodatkiem SP1, Windows 2008 R2-SP1 i Windows 2012 do usługi Azure Stack HCI. Spowoduje to obejście ograniczenia minimalnej obsługiwanej wersji maszyny wirtualnej dla tych starszych maszyn wirtualnych. Zalecamy tę opcję dla maszyn wirtualnych hostowanych w systemach Windows Server 2008 z dodatkiem SP1 i Windows Server 2008 R2-SP1.
Maszyny wirtualne hostowane w systemach Windows 2008 z dodatkiem SP1 i Windows 2008 R2-SP1 obsługują tylko maszyny wirtualne generacji 1 z dyskami VHD generacji 1. W związku z tym odpowiednie maszyny wirtualne generacji 1 należy utworzyć w usłudze Azure Stack HCI, aby skopiowane dyski VHD mogły być dołączone do nowych maszyn wirtualnych. Należy pamiętać, że tych dysków VHD nie można uaktualnić do dysków VHD generacji 2.
Uwaga
Windows Server 2012 obsługuje maszyny wirtualne generacji 1 i 2. generacji.
Oto proces, którego używasz:
Skorzystaj z przykładowego narzędzia Robocopy, aby skopiować wirtualne dyski VHD bezpośrednio do usługi Azure Stack HCI:
Robocopy \\2012R2-Clus01\c$\clusterstorage\volume01\Hyper-V\ \\20H2-Clus01\c$\clusterstorage\volume01\Hyper-V\ /E /MT:32 /R:0 /w:1 /NFL /NDL /copyall /log:c:\log.txt /xfUtwórz nowe maszyny wirtualne generacji 1. Aby uzyskać szczegółowe informacje na temat tego, jak to zrobić, zobacz Zarządzanie maszynami wirtualnymi.
Dołącz skopiowane pliki VHD do nowych maszyn wirtualnych. Aby uzyskać szczegółowe informacje, zobacz Zarządzanie wirtualnymi dyskami twardymi (VHD)
Jako FYI następujące systemy operacyjne gościa systemu Windows Server obsługują maszyny wirtualne generacji 2:
- Windows Server 2019
- Windows Server 2016
- Windows Server 2012 z dodatkiem R2
- Windows Server 2012
- Windows 10
- 64-bitowe wersje Windows 8.1 (64-bitowe)
- 64-bitowe wersje Windows 8 (64-bitowe)
- Linux (zobacz Obsługiwane maszyny wirtualne z systemami Linux i FreeBSD)
Następne kroki
Weryfikacja klastra po migracji. Zobacz Weryfikowanie klastra rozwiązania Azure Stack HCI.
Aby przeprowadzić migrację do rozwiązania Azure Stack HCI w miejscu przy użyciu tego samego sprzętu, zobacz Migrowanie do rozwiązania Azure Stack HCI na tym samym sprzęcie.
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla