Live migration w bhyve na FreeBSD 15.1: pierwsza działająca implementacja i co z tego wynika dla firm

Na FreeBSD 15.1 pojawiła się pierwsza działająca implementacja migracji live maszyn wirtualnych bhyve. Autorem jest deweloper związany z projektami Sylve i BoxyBSD, a kod i narzędzia testowe opublikowano jako WIP RFC — czyli wersję roboczą do publicznej oceny, a nie gotowy produkt. W praktyce oznacza to, że uruchomionego gościa amd64 można przenieść między dwoma hostami przez TCP, pauzując go tylko na końcową fazę stop-and-copy. Reszta pracy — przesyłanie pamięci i śledzenie zmienionych stron — odbywa się przy działającej maszynie.

Sprawa dotyczy przede wszystkim administratorów, którzy utrzymują wirtualizację na FreeBSD i szukają alternatywy dla VMware czy Proxmoxa, a także osób śledzących projekty Sylve i BoxyBSD. Jest ważna z dwóch powodów. Po pierwsze, live migration to od lat jedna z głównych luk funkcjonalnych bhyve — bez niej planowane prace serwisowe na hoście zwykle wymagają przerwy w działaniu gościa. Po drugie, publikacja pokazuje konkretny stan techniczny, a nie zapowiedź: autor sam wskazuje, że to prototyp bez obietnicy wsparcia produkcyjnego i bez pełnego dowodu poprawności. To rozróżnienie jest tu kluczowe, bo wokół migracji live w bhyve narosło sporo oczekiwań.

Co dokładnie zostało opublikowane

Materiał dowodowy pochodzi z bloga autora projektu, czyli źródła quasi-pierwotnego dla tego konkretnego przedsięwzięcia. Nie jest to oficjalne stanowisko FreeBSD Foundation ani commit w drzewie FreeBSD. Autor zapowiada publikację kodu co najmniej jako propozycji w swoim repozytorium Git i na GitHubie, a część osób ma już do niego dostęp. Na moment pisania nie mamy potwierdzenia, że kod trafił do oficjalnego drzewa FreeBSD.

Zakres deklarowany w materiale:

• działa wyłącznie na gościach amd64,
• opiera się na eksperymentalnym wsparciu snapshotów bhyve (BHYVE_SNAPSHOT),
• dodaje dirty-page tracking w module jądra vmm oraz protokół migracji w bhyve i bhyvectl,
• obsługuje tryb pre-copy oraz jawny warm stop-and-copy,
• wymaga urządzeń emulowanych ze wsparciem snapshotów; PCI passthrough nie jest migrowalne,
• transport odbywa się przez TCP bez uwierzytelniania i szyfrowania.

To deklaracje autora. Nie mamy niezależnych testów potwierdzających te wyniki poza środowiskiem, które sam opisał.

Tło techniczne bez żargonu

Migracja live polega na przeniesieniu działającej maszyny z jednego fizycznego serwera na drugi tak, aby aplikacja w środku nie zauważyła przerwy dłuższej niż ułamki sekundy. W wirtualizacji to nie jest kopiowanie pliku z dysku — trzeba przenieść stan pamięci, procesorów wirtualnych i urządzeń emulowanych, a przy tym nie zgubić zapisów, które gość wykonuje w trakcie transferu.

Pre-copy: wysyłaj pamięć, aż zbiór zmian przestanie rosnąć

Implementacja zaczyna od fazy pre-copy. Najpierw wysyła zapełnioną pamięć gościa, potem wielokrotnie pobiera bitmapę stron zmienionych od poprzedniego przebiegu i dosyła tylko te strony. Rundy powtarzają się, dopóki spełniony jest jeden z trzech warunków: pozostały zbiór zmienionych stron mieści się w skonfigurowanym celu downtime, zbiór przestaje się zmniejszać albo osiągnięty zostaje limit rund. Wtedy bhyve pauzuje gościa i jego urządzenia, wysyła ostatnie zmienione strony oraz istniejący stan snapshotu procesorów wirtualnych, jądra i urządzeń emulowanych. Cel waliduje podstawową geometrię maszyny, odbiera pamięć i stan, przywraca je i zgłasza gotowość. Dopiero wtedy źródło wysyła GO — punkt commit.

Kolejność ma znaczenie operacyjne. Przed GO nieudana migracja może wznowić gościa na źródle, a cel nie uruchomi maszyny bez komunikatu commit. To rozsądny projekt, ale autor sam zaznacza, że granica efektów ubocznych po stronie urządzeń wymaga przeglądu — chodzi o to, by przywracanie urządzeń na celu nie wywołało widocznych na zewnątrz skutków, zanim źródło zatwierdzi migrację.

Warm stop-and-copy: prostszy wariant awaryjny

Dostępny jest też tryb warm stop-and-copy, w którym gość jest zatrzymywany wcześniej, a cała pamięć i stan są przenoszone w jednej fazie. Autor opisuje go jako fallback i punkt odniesienia dla porównań. Dla administratora to istotne: jeśli pre-copy nie zbiegnie się w rozsądnym czasie, implementacja ma wracać do poprawnego zakończenia stop-and-copy, tyle że z dłuższą pauzą.

Co pilnuje spójności

Dirty-page tracking obejmuje zapisy gościa oraz zapisy przez mapowaną emulację, a write holds vmm są rejestrowane osobno. Obciążenie testowe przepisuje i weryfikuje pamięć gościa, zgłaszając brakującą lub nieaktualną stronę jako niezgodność. Powtarzane migracje w tę i z powrotem (ping-pong) służą sprawdzeniu, że obciążenie działa dalej bez błędów. Zapisy dyskowe są walidowane przez fsync, sumy kontrolne i ponowne sprawdzenie po zimnym restarcie — to test ścieżki pauzy, opróżniania i przywracania urządzeń.

Testowano też scenariusze awarii: odmowę celu, nieosiągalny cel oraz zniknięcie celu w fazie pre-copy i stop-and-copy. Przed commitem źródło ma wznowić zatrzymanego gościa po niepowodzeniu. Cel sprawdza wersję protokołu, rozmiar strony, układ pamięci i liczbę vCPU przed transferem danych. Socket migracji otwiera bhyvectl i przekazuje do bhyve, żeby ten pozostał w sandboxie Capsicum.

Realne konsekwencje: co to zmienia, a czego nie

Najważniejsza konsekwencja jest operacyjna, nie wydajnościowa. Jeśli migracja live działa wiarygodnie, prace serwisowe na hoście — wymiana sprzętu, aktualizacje jądra, przenoszenie obciążenia — przestają wymagać planowanej przerwy w działaniu gościa. Dla platformy klastrowej to warunek konieczny, żeby mówić o zarządzaniu domenami awarii i równoważeniem obciążenia. Autor wprost wskazuje, że bez wiarygodnej ścieżki migracji rutynowe prace na hoście wymagają przerwy, co dla BoxyBSD jest obecnie blokerem, a dla Sylve — elementem, bez którego klastrowa eksploatacja jest niepraktyczna.

Druga konsekwencja jest mniej oczywista: publikacja porządkuje rozmowę o dojrzałości. Do tej pory live migration w bhyve była tematem teoretycznym. Teraz jest prototyp z listą znanych braków, co pozwala firmom ocenić ryzyko na podstawie konkretów, a nie ogólnych deklaracji.

Czego to nie zmienia: nie mamy podstaw, by traktować tę implementację jako produkcyjną. Autor sam wymienia blokery przed upstreamem i podkreśla, że wyniki są zachęcające inżyniersko, ale nie stanowią obietnicy wsparcia ani dowodu poprawności. To nie jest wersja, którą można wdrożyć w firmie bez własnych testów i świadomej akceptacji ryzyka.

Scenariusze ryzyka

Poniższe punkty wynikają z ograniczeń opisanych w materiale. To interpretacja ryzyka, nie dodatkowe fakty o kodzie.

Obszar	Ryzyko	Kogo dotyczy najmocniej
Wielordzeniowe goście	Testy prowadzono głównie na jednym vCPU; testy obciążeniowe i wyścigów przy wielu vCPU są nadal wymagane	Firmy z bazami danych i aplikacjami wielowątkowymi
PCI passthrough	Nie jest migrowalne; maszyny z przypisanymi kartami nie przeniosą się	Środowiska z GPU, kartami sieciowymi, kontrolerami NVMe
BHYVE_SNAPSHOT	Zależność od eksperymentalnego wsparcia snapshotów	Wszyscy, którzy liczą na stabilne API
Transport TCP	Brak uwierzytelniania i szyfrowania w pierwszej wersji protokołu	Sieci między hostami poza zamkniętym segmentem
Pamięć i dysk	Wymagane zdefiniowane założenia spójności, trwałości i fencing dla współdzielonego storage’u	Klastry z współdzielonym storage’em
Sieć gościa	Brak sprecyzowanego przenoszenia tap/bridge, MAC/IP i zbieżności ruchu	Usługi sieciowe zależne od adresacji
Szybko brudzący się gość	Pre-copy może się nie zbiec; spadek do stop-and-copy z dłuższą pauzą	Obciążenia o wysokiej intensywności zapisów do pamięci

Osobno warto potraktować kwestię poprawności dirty-log. Autor wprost wymaga dowodu, że algorytm po stronie jądra nie gubi zapisu w momencie sprawdzania i czyszczenia bitów dirty. To najbardziej newralgiczny element całej konstrukcji: błąd tutaj oznacza cichą utratę danych w gościu, a nie widoczny błąd migracji. Dopóki nie ma przeglądalnego uzasadnienia blokad i kolejności pamięci oraz testów współbieżności, zaufanie do tej ścieżki musi być ograniczone.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

To nie jest podatność ani aktualizacja bezpieczeństwa, więc nie ma tu listy podatnych wersji. Pytanie brzmi raczej: czy ten projekt jest dla Ciebie istotny operacyjnie.

1. Sprawdź, czy utrzymujesz wirtualizację na FreeBSD z bhyve. Jeśli nie — temat jest na razie niszowy.
2. Sprawdź, czy Twoje maszyny korzystają z PCI passthrough. Jeśli tak, migracja live w tej implementacji ich nie obejmie.
3. Sprawdź, czy goście mają wiele vCPU. Jeśli tak, pamiętaj, że testy wielordzeniowe są deklarowane jako niewykonane w wystarczającym zakresie.
4. Sprawdź, czy hosty łączy sieć, której nie kontrolujesz w pełni. Transport bez uwierzytelniania i szyfrowania wymaga wtedy dodatkowego zabezpieczenia na poziomie sieci.
5. Sprawdź, czy używasz współdzielonego storage’u. Bez zdefiniowanych założeń spójności, trwałości i fencing nie ma podstaw do migracji w klastrze.
6. Sprawdź, czy planujesz opierać się na Sylve lub BoxyBSD. Dla tych projektów migracja jest warunkiem rozwoju, ale to nie znaczy, że jest gotowa do wdrożenia.

Plan reakcji krok po kroku

Dla zespołów, które chcą realnie ocenić prototyp, sensowna kolejność jest następująca:

1. Ustal cel. Czy chcesz tylko śledzić projekt, czy planujesz testy w laboratorium. To dwie różne decyzje i różny nakład pracy.
2. Zbuduj izolowane środowisko. Dwa hosty z FreeBSD 15.1, sieć testowa, żadnych danych produkcyjnych.
3. Zacznij od jednego vCPU i małej pamięci. To zakres, który autor opisał jako przetestowany. Dopiero potem zwiększaj złożoność.
4. Weryfikuj pamięć i dysk. Użyj obciążeń, które przepisują pamięć i zapisują pliki z fsync oraz sumami kontrolnymi, i sprawdź wynik po zimnym restarcie.
5. Testuj awarie. Odmowa celu, nieosiągalny cel, zniknięcie celu w obu fazach. Sprawdź, czy źródło wznawia gościa przed commitem.
6. Testuj wielordzeniowe goście ostrożnie. Traktuj wynik jako obserwację, nie jako potwierdzenie gotowości.
7. Zabezpiecz transport. Skoro protokół nie ma uwierzytelniania ani szyfrowania, uruchamiaj testy wyłącznie w segmencie, do którego nie ma dostępu nikt niepowołany.
8. Udokumentuj wyniki i zgłoś je autorowi. Projekt jest publikowany jako RFC właśnie po to, by zbierać uwagi do projektu.

Typowe błędy

• Traktowanie WIP RFC jako funkcji produkcyjnej. Autor wprost pisze, że to nie jest obietnica wsparcia.
• Pomijanie wielordzeniowych gości w testach. Skoro testy wielordzeniowe są nadal wymagane, wniosek „działa u mnie na jednym vCPU, więc zadziała wszędzie” jest nieuprawniony.
• Liczenie na migrację maszyn z PCI passthrough. W tej implementacji to nie działa.
• Uruchamianie migracji przez sieć bez dodatkowej ochrony. Pierwsza wersja protokołu nie ma uwierzytelniania ani szyfrowania.
• Zakładanie, że zgodność rozmiaru pamięci i liczby vCPU wystarczy. Autor wymaga szerszego kontraktu zgodności: tożsamości gościa, możliwości CPU, zgodności formatu snapshotów, topologii urządzeń i tożsamości współdzielonego storage’u.
• Ignorowanie granicy commitu. Skutki uboczne po stronie urządzeń przed zatwierdzeniem migracji to obszar wymagający przeglądu, a nie szczegół do pominięcia.
• Oczekiwanie, że pre-copy zawsze się zbiegnie. Przy szybko brudzącym się gościu implementacja spada do stop-and-copy z dłuższą pauzą.

Działania krótkoterminowe

Jeśli interesuje Cię ten projekt, w najbliższym czasie sensowne są: lektura materiału autora i śledzenie repozytoriów, na których ma się pojawić kod; przygotowanie izolowanego laboratorium; zebranie własnych wymagań wobec migracji — zwłaszcza liczby vCPU, urządzeń i modelu storage’u — żeby ocenić, czy prototyp w ogóle odpowiada Twojemu scenariuszowi. Warto też ustalić wewnętrznie, kto odpowiada za testy i jakie kryteria muszą być spełnione, by w ogóle rozważać wdrożenie.

Działania długoterminowe

W horyzoncie dłuższym kluczowe jest to, co wydarzy się z listą blokerów przed upstreamem. Autor wymienia: dowód i utwardzenie poprawności dirty-log, pełny kontrakt zgodności, utwardzenie transportu i protokołu, wyjaśnienie granicy commitu i efektów ubocznych urządzeń, sprecyzowanie przekazania storage’u i sieci, strategię testów w drzewie oraz podział pracy na przeglądalne patche. Dopiero po ich domknięciu można odpowiedzialnie oceniać upstream do FreeBSD. Firmy planujące opierać się na bhyve powinny śledzić, czy te punkty są zamykane, a nie tylko czy pojawiają się nowe funkcje — autor sam deklaruje, że najbliższy fokus to poprawność, walidacja zgodności, bezpieczeństwo transportu i powtarzalne testy, a nie wydajność.

Praktyczna checklista

• Czy wiem, że to WIP RFC, a nie funkcja produkcyjna?
• Czy moje goście są amd64?
• Czy korzystam z PCI passthrough?
• Czy moje goście mają więcej niż jeden vCPU i czy mam plan testów wielordzeniowych?
• Czy akceptuję zależność od eksperymentalnego BHYVE_SNAPSHOT?
• Czy transport migracji będzie w sieci pod moją kontrolą?
• Czy mam zdefiniowane założenia spójności, trwałości i fencing dla storage’u?
• Czy mam plan na sieć gościa: tap/bridge, MAC/IP, zbieżność ruchu?
• Czy mam testy pamięci i zapisów dyskowych z weryfikacją po zimnym restarcie?
• Czy mam przetestowane scenariusze awarii celu przed commitem?
• Czy wiem, kto w organizacji oceni wyniki i zgłosi uwagi do RFC?

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy nie musi znać szczegółów dirty-page trackingu, ale powinien zrozumieć jedną rzecz: to jest prototyp, który może w przyszłości usunąć jedną z głównych przeszkód we wdrażaniu klastrów wirtualizacji na FreeBSD. Na dziś nie jest podstawą do przenoszenia na niego obciążeń produkcyjnych. Decyzja „śledzimy” jest tania i sensowna; decyzja „wdrażamy” wymagałaby własnych testów, akceptacji ryzyka i gotowości do wycofania się.

Administrator powinien natomiast:

• przeczytać materiał autora w całości, ze szczególnym uwzględnieniem sekcji o blokerach przed upstreamem,
• nie wdrażać prototypu na danych produkcyjnych,
• przygotować laboratorium odpowiadające realnemu profilowi obciążeń, w tym wielordzeniowym gościom,
• przetestować scenariusze awarii, bo to one decydują o bezpieczeństwie operacyjnym,
• zabezpieczyć sieć migracji niezależnie od tego, co robi protokół,
• nie zakładać migracji maszyn z PCI passthrough,
• traktować deklaracje autora jako deklaracje, a własne wyniki jako jedyną podstawę decyzji,
• zgłaszać uwagi do projektu — RFC jest po to, by wpływać na kształt kolejnych kroków.

Podsumowanie

Pierwsza działająca implementacja live migration dla bhyve na FreeBSD 15.1 to istotny krok dla ekosystemu wirtualizacji na FreeBSD. Autor pokazał działający mechanizm pre-copy z punktem commit, fallbackiem stop-and-copy, testami pamięci, dysku i awarii, a przy tym sam wskazał, czego jeszcze brakuje: dowodu poprawności dirty-log, pełnego kontraktu zgodności, bezpiecznego transportu, sprecyzowanego przekazania storage’u i sieci oraz testów w drzewie. Dla firm to sygnał do śledzenia i ewentualnych testów w laboratorium, nie do wdrożeń. Dla społeczności FreeBSD — zaproszenie do przeglądu, które zdecyduje, czy prototyp stanie się funkcją, czy pozostanie eksperymentem.

Praktyczna weryfikacja w laboratorium: co mierzyć i jak dokumentować wyniki

Weryfikacja prototypu live migration dla bhyve nie powinna sprowadzać się do jednorazowego „udało się przenieść gościa”. Sensowna ocena wymaga powtarzalnego zestawu pomiarów, które da się porównać między kolejnymi wersjami kodu i między konfiguracjami hostów. Poniżej praktyczny zakres, który odpowiada temu, co autor opisał jako faktycznie przetestowane.

Pomiar czasu pauzy gościa

Automatyczny pomiar downtime’u jest podstawą. Dla wolno brudzącego się gościa o rozmiarze 512 MiB autor zaobserwował downtime rzędu 138–171 ms. Własne pomiary warto prowadzić w tej samej skali i zapisywać je razem z parametrami: rozmiarem pamięci gościa, liczbą vCPU, konfiguracją limitu downtime i limitu rund pre-copy. Bez tych parametrów sam wynik w milisekundach jest bezużyteczny przy porównaniach.

Weryfikacja spójności pamięci

Obciążenie po stronie gościa powinno wielokrotnie przepisywać pamięć i weryfikować jej zawartość. Każda brakująca lub nieaktualna strona to mismatch, który trzeba odnotować. Warto prowadzić serię migracji „ping-pong” — tam i z powrotem między hostami — i sprawdzać, czy obciążenie kontynuuje pracę bez błędów po każdej z nich. To odzwierciedla sposób, w jaki autor wykorzystywał testy do sprawdzania poprawności dirty-page trackingu.

Weryfikacja zapisów dyskowych

Obciążenie zapisujące pliki z fsync i sumami kontrolnymi, a następnie ponowna weryfikacja sum po zimnym restarcie, ćwiczy ścieżkę pauzy, opróżnienia i przywrócenia urządzeń. Wynik należy zapisywać oddzielnie od wyników pamięci — to dwa różne obszary ryzyka i mieszanie ich w jednym raporcie zaciemnia obraz.

Rejestr scenariuszy awarii

Każdy test awarii powinien mieć udokumentowany wynik: odmowa celu, nieosiągalny cel oraz zniknięcie celu w fazie pre-copy i w fazie stop-and-copy. Dla każdego przypadku zapisz, czy źródło wznowiło gościa przed commitem i czy cel odmówił startu gościa bez otrzymania komunikatu GO. To zachowania, które autor wskazuje jako zaprojektowane, więc test ma potwierdzić, że działają w Twoim środowisku.

Monitoring po wdrożeniu — nawet jeśli „wdrożenie” oznacza tylko laboratorium

Nawet w środowisku testowym warto od pierwszego dnia zbierać dane w sposób, który pozwoli wychwycić regresje między kolejnymi wersjami prototypu. Poniższe punkty wynikają wprost z ograniczeń i mechanizmów opisanych przez autora.

Co obserwować podczas każdej migracji

• Czas trwania fazy pre-copy i liczbę rund — pozwalają zauważyć, czy gość zaczyna brudzić się szybciej niż wcześniej.
• Czy migracja zakończyła się w trybie pre-copy, czy spadła do stop-and-copy — szybko brudzący się gość może nie zbiec się w pre-copy i wtedy pauza jest dłuższa.
• Czas pauzy w fazie finalnej — porównuj z wcześniejszymi pomiarami dla tego samego profilu gościa.
• Wynik walidacji geometrii VM po stronie celu: wersja protokołu, rozmiar strony, układ pamięci, liczba vCPU. Odrzucenie na tym etapie to sygnał niezgodności konfiguracji hostów, nie awaria sieci.
• Obecność i poprawność komunikatu GO — brak GO oznacza, że cel nie powinien uruchomić gościa, i taki stan trzeba traktować jako zdarzenie do zbadania, a nie jako „prawie udaną” migrację.

Monitoring sieci migracji

Skoro transport migracji działa po TCP, a pierwsza wersja protokołu nie ma uwierzytelniania ani szyfrowania, monitoring powinien obejmować wyłącznie segment, do którego nie ma dostępu nikt niepowołany. Warto rejestrować, które hosty i w jakich oknach czasowych inicjowały połączenia migracyjne, oraz alarmować o próbach połączeń z adresów spoza listy dozwolonych. To nie zastępuje utwardzenia protokołu, ale ogranicza ekspozycję do czasu, aż transport zostanie zabezpieczony.

Monitoring po stronie celu

Cel powinien raportować, czy otrzymał komplet danych i stanu przed startem gościa, oraz czy odrzucił migrację z powodu niezgodności liczby vCPU lub geometrii pamięci. Odrzucenia należy korelować z konfiguracją hostów — powtarzające się odrzucenia wskazują na dryf konfiguracji między hostami, a nie na problem z samym protokołem.

Checklista weryfikacji przed każdym testem migracji

1. Czy oba hosty działają na FreeBSD 15.1 i mają włączone eksperymentalne wsparcie BHYVE_SNAPSHOT?
2. Czy gość jest wyłącznie amd64?
3. Czy gość nie korzysta z PCI passthrough — w tej implementacji takie urządzenia nie są migrowalne?
4. Czy urządzenia emulowane w gościu obsługują snapshoty?
5. Czy znasz liczbę vCPU gościa i czy handshake potwierdził jej zgodność po obu stronach?
6. Czy masz zapisane parametry pre-copy: docelowy downtime i limit rund?
7. Czy sieć migracji jest odizolowana od ruchu, którego nie kontrolujesz?
8. Czy masz przygotowane obciążenie weryfikujące pamięć oraz obciążenie zapisujące pliki z fsync i sumami kontrolnymi?
9. Czy masz zaplanowany test po zimnym restarcie gościa po migracji?
10. Czy masz przygotowane scenariusze: odmowa celu, nieosiągalny cel, zniknięcie celu w pre-copy i w stop-and-copy?
11. Czy wiesz, gdzie zapiszesz wyniki pomiarów downtime’u i liczby rund, żeby dało się je porównać z kolejną wersją prototypu?
12. Czy dane w gościu są wyłącznie testowe i nie ma ryzyka, że trafią do środowiska produkcyjnego?

Checklista po zakończonym teście

• Czy downtime mieści się w założonym przedziale i czy został zapisany razem z parametrami pre-copy?
• Czy obciążenie pamięci zgłosiło jakiekolwiek mismatche — brakujące lub nieaktualne strony?
• Czy seria migracji ping-pong zakończyła się bez błędów po stronie obciążenia?
• Czy sumy kontrolne plików zgadzają się po migracji i po zimnym restarcie?
• Czy w scenariuszach awarii przed commitem źródło wznowiło gościa?
• Czy w scenariuszach awarii cel nie uruchomił gościa bez komunikatu GO?
• Czy w logach nie ma odrzuceń geometrii VM ani niezgodności liczby vCPU, których nie potrafisz wyjaśnić konfiguracją?
• Czy wiesz, czy migracja zakończyła się w pre-copy, czy spadła do stop-and-copy, i czy potrafisz to przypisać profilowi obciążenia?
• Czy wyniki są zapisane w formie umożliwiającej porównanie z kolejną wersją kodu?
• Czy masz listę uwag do zgłoszenia w ramach RFC — zwłaszcza dotyczących obszarów, które autor wskazał jako wymagające dalszej pracy?

Jak odróżnić „działa” od „jest gotowe”

Prototyp został opublikowany jako WIP RFC, a nie jako funkcja produkcyjna. Wynik testu na jednym vCPU i małej pamięci potwierdza jedynie zakres, który autor sam opisał jako przetestowany. Testy wielordzeniowych gości są deklarowane jako nadal wymagane, więc ich wynik należy traktować jako obserwację, nie jako potwierdzenie gotowości. Podobnie wynik testu z PCI passthrough nie może być pozytywny, bo ta ścieżka nie jest w tej implementacji migrowalna. Checklisty powyżej służą do tego, by każdy test kończył się jasnym stwierdzeniem: co zostało sprawdzone, w jakich warunkach i czego na tej podstawie nie wolno twierdzić.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. FreeBSD bhyve Live Migration: Moving VMs Between Hosts (gyptazy.com)
2. FreeBSD bhyve Live Migration: Moving VMs Between Hosts (gyptazy.com)

Zdjęcie wyróżniające: panumas nikhomkhai / Pexels.