Najbezpieczniejsza odpowiedź na ten nierozstrzygnięty wątek źródłowy brzmi: nie rób z istniejącego mirrora Btrfs w OMV pierwszego obiektu eksperymentów. Pozostaw OpenMediaVault działający, zainstaluj ZimaOS na osobnym systemie, który chcesz przetestować, podłącz udziały OMV jako pamięć LAN i kopiuj dane etapami. Dzięki temu stary NAS pozostanie zarówno działającą usługą, jak i ścieżką powrotu podczas testowania aplikacji, udziałów i kopii zapasowych w ZimaOS.
Kwestia procesora również staje się prostsza, gdy podzielimy ją na warstwy. VT-x to kluczowa funkcja sprzętowej wirtualizacji dla zwykłych maszyn wirtualnych x86. VT-d/IOMMU ma znaczenie głównie wtedy, gdy chcesz bezpośrednio przekazywać fizyczne urządzenia PCIe do systemu gościa. Aplikacje Docker nie wymagają VT-d. Procesor i5-2310 z 2011 roku może więc nadal uruchamiać kontenery, a także zwykłe maszyny wirtualne, jednak przekazywanie urządzeń i ogólna wydajność VM to osobne ograniczenia.
Aplikacje Docker nie wymagają VT-d
Aplikacje ze sklepu ZimaOS działają jako kontenery Docker. Korzystają ze wspólnego jądra hosta i nie potrzebują przekazywania urządzeń sprzętowych tylko po to, aby się uruchomić.
Stary i5 może być powolny w przypadku cięższych aplikacji, ale brak VT-d nie oznacza „braku aplikacji”. W przypadku zwykłych kontenerów większe znaczenie mają pamięć RAM, szybkość pamięci masowej i obciążenie procesora przez aplikację.
VT-x może obsługiwać zwykłe maszyny wirtualne
Aktualne wytyczne dotyczące planowania maszyn wirtualnych w ZimaOS rozdzielają podstawową wirtualizację KVM/QEMU od przekazywania urządzeń PCIe/GPU. Zwykłe systemy gościa Linux/Windows wymagają działającej obsługi wirtualizacji oraz odpowiedniej ilości zasobów procesora i pamięci RAM hosta.
Skorzystaj z aktualnego przewodnika sprzętowego dotyczącego maszyn wirtualnych ZimaOS.
VT-d to przede wszystkim granica przekazywania urządzeń
Jeśli system gościa musi bezpośrednio sterować kartą GPU PCIe, kontrolerem HBA, kartą sieciową lub podobnym urządzeniem, IOMMU/VT-d staje się istotne. Przekazywanie urządzeń USB może również zależeć od sposobu udostępniania kontrolerów/urządzeń USB przez hosta oraz od używanego interfejsu ZVM.
Nie utożsamiaj faktu, że „maszyna wirtualna się uruchamia”, z możliwością przypisania jej każdego fizycznego urządzenia.
Nie zakładaj, że ZimaOS przejmie istniejący mirror Btrfs z OMV bezpośrednio
Użytkownik źródłowy miał dwudyskowy mirror Btrfs utworzony i zarządzany przez OMV. Aktualna dokumentacja pamięci masowej ZimaOS koncentruje się na tworzeniu i zarządzaniu przestrzeniami pamięci masowej ZimaOS za pomocą własnego procesu Storage. Nie gwarantuje ona ogólnej możliwości niedestrukcyjnego importu dowolnych, wcześniej utworzonych układów RAID Btrfs z OMV.
Jeśli te dyski o pojemności 16 TB zawierają jedyną kopię ważnych danych, pozostaw je pod kontrolą OMV do czasu niezależnego wykonania kopii zapasowej lub skopiowania danych.
Obecnie oficjalną ścieżką migracji jest kopiowanie przez sieć
Aktualne zalecenia IceWhale dotyczące przeprowadzki z innego NAS-a mówią, aby pozostawić stary NAS działający, udostępnić jego zasoby, dodać go w aplikacji Files w ZimaOS jako pamięć LAN, a następnie skopiować dane do nowej pamięci masowej ZimaOS.
Skorzystaj z aktualnej strategii przenoszenia danych z innego NAS-a. Ta sama koncepcja migracji SMB dotyczy udziałów OMV.
Wydajny komputer Ryzen z ZimaOS może używać OMV jako pamięci sieciowej
Alternatywa ze źródła — uruchamianie aplikacji i maszyn wirtualnych na komputerze z Ryzenem 9, podczas gdy OMV nadal udostępnia dyski 16 TB — to rozsądne rozwiązanie przejściowe o niskim ryzyku. ZimaOS może montować pamięć sieciową za pośrednictwem aplikacji Files, a stary NAS pozostanie właścicielem pamięci masowej.
Praktycznym ograniczeniem będzie łącze 1GbE w komputerze OMV: przepustowość będzie mniej więcej na poziomie gigabitowego Ethernetu, niezależnie od karty sieciowej 2.5GbE w komputerze Ryzen.
USB JBOD jest opcją, ale zmienia model awarii
Aktualny ZimaOS obsługuje dyski USB jako niezależną pamięć masową oraz w obsługiwanych procesach konfiguracji pamięci. Przeniesienie dysków HDD do obudowy USB daje ZimaOS bezpośrednią kontrolę, ale obudowa i mostek USB stają się częścią ścieżki pamięci masowej.
W przypadku krytycznego, stale działającego RAID-u przed przeniesieniem dysków produkcyjnych sprawdź przekazywanie danych SMART, stabilność wykrywania urządzeń, dostarczanie zasilania, chłodzenie oraz zachowanie mostka USB.
Bezpieczniejsza kolejność migracji
- wykonaj kopię zapasową danych OMV;
- zainstaluj ZimaOS na oddzielnym sprzęcie lub nośniku;
- przetestuj aplikacje i jedną reprezentatywną maszynę wirtualną;
- zamontuj OMV jako pamięć LAN;
- skopiuj podzbiór danych i zweryfikuj uprawnienia oraz sumy kontrolne;
- utwórz końcową pamięć masową ZimaOS oddzielnie;
- skopiuj pozostałe dane;
- pozostaw OMV bez zmian do czasu zweryfikowania przywracania danych i kopii zapasowych.
Często zadawane pytania dotyczące OMV i ZimaOS
Czy brak VT-d oznacza brak aplikacji Docker?
Nie. Aplikacje Docker nie wymagają VT-d.
Czy brak VT-d oznacza brak zwykłych maszyn wirtualnych?
Niekoniecznie. VT-x może obsługiwać zwykłe maszyny wirtualne ze sprzętowym przyspieszeniem, natomiast VT-d jest przede wszystkim wymagane w przypadku zaawansowanego przekazywania urządzeń.
Czy powinienem pozwolić ZimaOS odtworzyć stary RAID OMV przed skopiowaniem danych?
Nie, jeśli zawiera on jedyną kopię danych. Pozostaw stary NAS bez zmian i najpierw przeprowadź migrację przez sieć.
