Jak korzystać z urządzeń RAW w maszynach wirtualnych

Podczas pracy z zaawansowaną wirtualizacją nadchodzi moment, w którym typowe obrazy dysków wirtualnych (VDI, VMDK, QCOW2 itp.) przestają być wystarczające. W tym momencie do gry wchodzą urządzenia RAW bezpośrednio powiązane z maszynami wirtualnymi , idealne do maksymalizacji wydajności pamięci masowej lub ponownego wykorzystania istniejących dysków i partycji bez konieczności kopiowania ich do innego formatu.

Ten typ konfiguracji jest szeroko stosowany w środowiskach takich jak VirtualBox, VMware i Proxmox , klastrach Oracle RAC oraz laboratoriach kryminalistycznych . Choć na początku może się to wydawać nieco zniechęcające, jeśli zrozumiesz, co robisz, możesz wiele z tego wyciągnąć. W tym artykule szczegółowo omówimy, jak korzystać z urządzeń RAW w maszynach wirtualnych na różnych hiperwizorach i w rzeczywistych scenariuszach , jakie oferują one korzyści i jakie środki ostrożności należy podjąć, aby uniknąć uszkodzenia danych.

Czym jest urządzenie RAW i dlaczego warto go używać w maszynach wirtualnych

Urządzenie RAW to w zasadzie bezpośredni, nieprzerwany punkt dostępu do dysku fizycznego, określonej partycji, woluminu LVM lub jednostki LUN prezentowanej z macierzy SAN. Nie jest to plik dysku wirtualnego, lecz samo urządzenie widziane przez system operacyjny hosta.

Podczas pracy ze standardowymi dyskami wirtualnymi, hiperwizor przechowuje dane w plikach .vdi, .vmdk, .qcow2, .raw itp. w systemie plików (VMFS, ext4, XFS, ZFS itp.). Natomiast w przypadku urządzenia RAW, maszyna wirtualna uzyskuje bezpośredni dostęp do bazowego bloku pamięci masowej, niezależnie od tego, czy jest to partycja lokalna, wolumin LVM, jednostka LUN iSCSI/Fibre Channel, czy też cały inny dysk.

Takie podejście oferuje szereg korzyści: mniejsze obciążenie, niemal natywny dostęp do sprzętu oraz możliwość ponownego wykorzystania istniejących dysków bez konwersji. W środowiskach klastrowych umożliwia również wielu maszynom wirtualnym dostęp do tego samego LUN i zarządzanie współdzielonym dostępem z poziomu systemu operacyjnego gościa lub oprogramowania klastra.

Jednak korzystanie z urządzeń RAW nie jest magiczne: wiąże się z rezygnacją (w zależności od trybu) z niektórych funkcji warstwy wirtualizacji , takich jak niektóre migawki czy łatwe klonowanie, i wymaga znacznie większej ostrożności, aby uniknąć nadpisania niewłaściwych dysków. Dlatego tak ważne jest, aby dokładnie zrozumieć, co każdy hiperwizor robi z tym typem mapowania.

Korzystanie z urządzeń RAW w VirtualBox

VirtualBox domyślnie tworzy maszyny wirtualne w plikach dyskowych, takich jak .vdi lub .vmdk; instrukcje dotyczące zarządzania nimi można znaleźć w sekcji Polecenia i przykłady VirtualBox . Umożliwia on jednak również korzystanie z surowych urządzeń hosta: całych dysków, określonych partycji lub woluminów LVM. Jest to bardzo przydatne, jeśli chcesz, aby maszyna wirtualna działała na wstępnie skonfigurowanym dysku lub jeśli potrzebujesz maksymalnej wydajności bez korzystania z warstwy plików.

Pomysł jest prosty: zamiast tworzyć nowy dysk wirtualny, należy polecić VirtualBoxowi „opakowanie” urządzenia fizycznego i udostępnienie go maszynie wirtualnej tak, jakby było to kolejny dysk. To „opakowanie” odbywa się za pomocą małego pliku deskryptora, który wskazuje na rzeczywiste urządzenie RAW (na przykład /dev/sdb lub /dev/mapper/vgdatos-lvvm1).

To podejście jest również przydatne w przypadku, gdy masz preinstalowany system operacyjny na dysku fizycznym lub LVM i chcesz go uruchomić na maszynie wirtualnej VirtualBox, zachowując oryginalną strukturę . Lub gdy chcesz użyć konkretnej partycji do testów bez wpływu na resztę dysku.

Co więcej, VirtualBox pozwala na pracę z formatami RAW w inny sposób: za pomocą narzędzia VBoxManage do konwersji obrazów z innych hiperwizorów do formatu RAW. Jest to często spotykane w scenariuszach analizy kryminalistycznej, gdzie ważne jest posiadanie zrzutu typu dd zawierającego wszystkie bajty oryginalnego dysku.

Konwertuj płyty VMDK do formatu RAW za pomocą VBoxManage

Bardzo częstą sytuacją jest otrzymanie maszyny wirtualnej VMware w formacie VMDK i chęć przeanalizowania tego dysku za pomocą narzędzi kryminalistycznych, takich jak FTK, Autopsy lub podobnych . W takich przypadkach zazwyczaj najlepiej jest przekonwertować obraz do zwykłego pliku RAW (takiego jak dd), zamiast pracować bezpośrednio z VMDK.

VirtualBox zawiera polecenie `VBoxManage clonehd` , które umożliwia klonowanie i formatowanie dysków. Typowe polecenie konwersji z VMDK do RAW wygląda mniej więcej tak:

VBoxManage clonehd source_file.vmdk destination_file.dd –format raw

Zaleca się używanie ścieżek bezwzględnych, aby uniknąć problemów, zwłaszcza jeśli pracujesz z wieloma dyskami i katalogami. Podczas konwersji VBoxManage skanuje wszystkie bloki pliku VMDK i kopiuje je dokładnie do nowego pliku RAW. Jeśli plik VMDK był dynamiczny, należy pamiętać, że wynikowy obraz RAW prawdopodobnie zajmie znacznie więcej miejsca w docelowym systemie plików.

Ważne jest, aby upewnić się, że masz wystarczająco dużo wolnego miejsca na dysku, na którym zapiszesz plik RAW, w przeciwnym razie wystąpią błędy w trakcie konwersji. Po zakończeniu procesu otrzymasz plik w standardowym formacie dd, z którym możesz łatwo pracować w pakietach analitycznych, a nawet mapować z poziomu innych hiperwizorów.

Surowe mapowanie urządzeń (RDM) w VMware vSphere/ESXi

W ekosystemie VMware klasycznym sposobem zapewnienia maszynie wirtualnej bezpośredniego dostępu do fizycznego LUN jest Raw Device Mapping (RDM) . Ta technika jest wykorzystywana głównie podczas pracy z macierzami pamięci masowej iSCSI lub Fibre Channel, gdzie maszyna wirtualna musi widzieć wolumin niemal tak, jakby była bezpośrednio podłączona do systemu.

Zamiast tworzyć dysk wirtualny w magazynie danych VMFS, RDM tworzy specjalny plik mapowania na woluminie VMFS , który działa jako dowiązanie symboliczne do fizycznej jednostki LUN. Z perspektywy maszyny wirtualnej plik ten wygląda jak kolejny dysk, ale w rzeczywistości dostęp jest przekierowywany do surowego urządzenia pamięci masowej.

Takie podejście pozwala zachować niektóre zalety systemu VMFS (takie jak scentralizowane zarządzanie i pewna kontrola uprawnień), podczas gdy operacje wejścia/wyjścia na dysku są wykonywane bezpośrednio na jednostce LUN . Jest to szczególnie przydatne w środowiskach klastrowych, w których kilka maszyn wirtualnych współdzieli pamięć masową i wymaga, aby system gościnny zarządzał blokadami, lub w aplikacjach wymagających bardzo precyzyjnej kontroli SCSI.

Podczas konfiguracji RDM, VMware oferuje wybór pomiędzy dwoma trybami: wirtualnym i fizycznym . Wybór ten decyduje o tym, z których funkcji VMware nadal będziesz mógł korzystać oraz jaki poziom dostępu ma maszyna wirtualna do urządzenia pamięci masowej.

Tryby zgodności: wirtualny i fizyczny

Tryb zgodności wirtualnej sprawia, że ​​RDM zachowuje się, z perspektywy VMware, niemal jak normalny plik dysku wirtualnego. Oznacza to, że nadal można korzystać z funkcji takich jak migawki maszyn wirtualnych , mimo że bazowym magazynem jest surowy LUN. To dobry kompromis, gdy zależy Ci na prostocie i pewnych funkcjach zarządzania, ale nie potrzebujesz dostępu niskiego poziomu SCSI.

Z kolei tryb zgodności fizycznej zapewnia maszynie wirtualnej praktycznie bezpośredni dostęp do urządzenia SCSI. Jest to odpowiednia opcja dla aplikacji wymagających zaawansowanych poleceń SCSI lub samodzielnego zarządzania wieloma ścieżkami, a także dla niektórych scenariuszy klastrowych, w których system operacyjny gościa przejmuje pełną kontrolę nad głośnością.

Jednak w trybie zgodności fizycznej tracimy część magii wirtualizacji: nie wszystkie typy migawek i operacji klonowania będą dostępne lub będą zachowywać się tak samo, właśnie dlatego, że VMware w jak najmniejszym stopniu ingeruje pomiędzy maszyną wirtualną a dyskiem.

Ogólne kroki tworzenia RDM w VMware

Aby utworzyć RDM, przepływ pracy w kliencie vSphere jest zazwyczaj podobny do poniższego. Najpierw na jednej z maszyn wirtualnych, która będzie korzystać z surowego LUN:

1. Wybierz maszynę wirtualną i wejdź w „Edytuj ustawienia” z menu kontekstowego.
2. Dotknij Dodaj > Dysk twardy aby dodać nowy dysk.
3. Wybierz opcję Zmapowany SAN LUN lub ekwiwalent.
4. Wybierz fizyczny LUN, który chcesz zamapować z kokpitu.
5. Określ, w którym magazynie danych VMFS chcesz zapisać plik mapowania.
6. Wybierz Fizyczne lub wirtualne jako tryb zgodności, jak omówiono wcześniej.
7. Zostanie utworzony nowy kontroler SCSI dla dysku RDM, wybierając nowy węzeł urządzenia wirtualnego (na przykład SCSI 3:0) różni się od dysku głównego maszyny wirtualnej.

W przypadku innych maszyn wirtualnych, które również będą korzystać z tego samego współdzielonego LUN-u, procedura jest podobna, ale z jedną zasadniczą różnicą: zamiast tworzyć nowy RDM, wykorzystywany jest ten, który już istnieje w magazynie danych.

Na tych dodatkowych maszynach wirtualnych:

1. Otwórz ponownie Edytuj ustawienia na maszynie wirtualnej.
2. Dotknij Dodaj > Dysk twardy.
3. Wybierz opcję Użyj istniejącego dysku aby ponownie wykorzystać już utworzony plik RDM.
4. Wybierz ten sam plik mapowania, co w pierwszym kroku.
5. Skonfiguruj nowy kontroler SCSI i węzeł urządzenia tak samo, jak w przypadku pierwszej maszyny wirtualnej, przestrzegając zaleceń firmy VMware dotyczących klastrów.

W ten sposób kilka maszyn wirtualnych może uzyskać dostęp do tego samego LUN-a w postaci surowej , co pozwala na kontrolę współbieżności i jednoczesnego dostępu do systemu operacyjnego gościa lub oprogramowania klastra.

Obrazy dysków Proxmox VE i RAW dla maszyn wirtualnych

Proxmox VE to kompleksowa platforma wirtualizacji typu open source, która umożliwia zarządzanie zarówno maszynami wirtualnymi KVM, jak i kontenerami LXC. Jedną z jej głównych zalet jest elastyczność w obsłudze dysków surowych , zarówno w przypadku tworzenia ich od podstaw, jak i importowania z innych środowisk i kojarzenia z istniejącymi maszynami wirtualnymi.

Dysk RAW, w tym kontekście, to plik zawierający kopię bajt po bajcie dysku fizycznego lub partycji . Nie zawiera żadnej kompresji ani dodatkowych funkcji; po prostu zawiera wszystkie bajty urządzenia w kolejności. Właśnie z tego powodu jest to wysoce kompatybilny i wygodny format do migracji maszyn wirtualnych między hiperwizorami lub przywracania kopii zapasowych z minimalną transformacją.

W Proxmox możesz tworzyć własne obrazy RAW za pomocą narzędzi takich jak vmdebootstrap oraz importować wstępnie wygenerowane obrazy RAW (np. zrzuty dd, konwersje z VBoxManage lub dane wyjściowe z innych hiperwizorów) i montować je jako dyski w maszynie wirtualnej.

Utwórz obraz dysku RAW za pomocą vmdebootstrap

Bardzo praktycznym sposobem na przygotowanie obrazu RAW dla Proxmox jest użycie narzędzia vmdebootstrap , które automatyzuje tworzenie systemu bazowego w pliku obrazu. Narzędzie to obsługuje partycjonowanie, formatowanie , instalację systemu, konfigurację GRUB-a i dodawanie podstawowych pakietów.

Typowy przykład polecenia generującego obraz RAW z minimalną konfiguracją może obejmować opcje takie jak:

vmdebootstrap –verbose –size 10GiB –serial-console –grub –no-extlinux –package openssh-server –package avahi-daemon –package qemu-guest-agent –hostname vm600 –enable-dhcp –customize=./copy_pub_ssh.sh –sparse –image vm600.raw

W tym typie polecenia definiujesz parametry, takie jak rozmiar dysku, pakiety do zainstalowania, nazwę hosta maszyny wirtualnej lub aktywację konsoli szeregowej . Po zakończeniu otrzymasz plik vm600.raw zawierający w pełni funkcjonalny system Linux , gotowy do zaimportowania do Proxmox jako dysk maszyny wirtualnej.

Utwórz maszynę wirtualną i skojarz dysk RAW w Proxmox

Następnym krokiem jest utworzenie pustej maszyny wirtualnej w Proxmox, a następnie zaimportowanie pliku RAW do skonfigurowanej pamięci masowej. Aby utworzyć maszynę wirtualną, można użyć polecenia `qm create` , definiując identyfikator maszyny wirtualnej, interfejs sieciowy i typ kontrolera dysku.

qm create 600 –net0 virtio,bridge=vmbr0 –name vm600 –serial0 socket –bootdisk scsi0 –scsihw virtio-scsi-pci –ostype l26

Tutaj wskazujemy na przykład, że chcemy, aby maszyna wirtualna miała identyfikator 600, aby używała VirtIO do sieci z mostem vmbr0, aby uruchamiała się z SCSI0 za pomocą kontrolera virtio-scsi-pci i aby systemem operacyjnym był nowoczesny Linux (l26).

Następnie importujemy obraz RAW do magazynu Proxmox przy użyciu qm importdisk :

qm importdisk 600 vm600.raw pvedir

W tym poleceniu 600 to identyfikator maszyny wirtualnej, vm600.raw to ścieżka do pliku obrazu, a pvedir to nazwa magazynu zdefiniowana w Proxmox (można to sprawdzić za pomocą pvesm status). Po zakończeniu importu dysk będzie oznaczony jako unused0 lub podobny w konfiguracji maszyny wirtualnej.

Aby maszyna wirtualna mogła faktycznie korzystać z tego dysku, musi on być skojarzony z kontrolerem , na przykład SCSI:

qm set 600 –scsi0 pvedir:600/vm-600-disk-1.raw

W ten sposób zaimportowany dysk RAW jest połączony z urządzeniem SCSI0 maszyny wirtualnej. Na koniec wystarczy uruchomić maszynę poleceniem `qm start 600` i dokończyć konfigurację z konsoli, tak jak w przypadku każdej innej maszyny wirtualnej.

Przesyłaj i importuj duże obrazy RAW do Proxmox

Podczas pracy z dużymi plikami RAW, przesłanie ich do Proxmox przez interfejs webowy może być niepraktyczne, a nawet niemożliwe. W takich przypadkach zaleca się użycie scp, rsync lub podobnych narzędzi do skopiowania obrazu do węzła Proxmox lub współdzielonej pamięci masowej przed uruchomieniem `qm importdisk`.

Po umieszczeniu pliku na hoście, przepływ pracy jest podobny do opisanego powyżej: utwórz lub wybierz maszynę wirtualną, zaimportuj dysk RAW do pamięci masowej i powiąż go jako urządzenie (scsi0, sata0 itd.), definiując odpowiedni typ kontrolera zgodnie z systemem operacyjnym gościa.

To samo podejście sprawdza się w przypadku migracji maszyn wirtualnych z innych platform : konwertujesz dyski do formatu RAW (jeśli jeszcze go nie mają), kopiujesz je do węzła Proxmox, importujesz za pomocą qm importdisk i na koniec dostosowujesz konfigurację maszyny wirtualnej ( sterowniki sieciowe , kontrolery, kolejność rozruchu itd.), aż będzie działać poprawnie.

Tworzenie kopii zapasowych maszyn wirtualnych z dyskami RAW w Proxmox

Pracując z obrazami dysków RAW w Proxmox, nie należy zapominać o tworzeniu kopii zapasowych i odzyskiwaniu danych po awarii . Oprócz wbudowanych kopii zapasowych Proxmox, dostępne są rozwiązania firm trzecich, takie jak Vinchin Backup & Recovery, które integrują się z hypervisorem i umożliwiają zaawansowane zarządzanie kopiami zapasowymi.

Vinchin oferuje rozwiązanie do tworzenia kopii zapasowych zaprojektowane specjalnie dla środowisk zwirtualizowanych, w tym Proxmox VE . Obsługuje pełne i przyrostowe kopie zapasowe maszyn wirtualnych, a także granularne i pełne przywracanie. Jest to szczególnie przydatne podczas pracy z maszynami wirtualnymi uruchamianymi z importowanych obrazów RAW, LVM lub ZFS , ponieważ narzędzie koordynuje cały proces, bez konieczności obsługi różnych formatów.

Przepływ pracy jest zazwyczaj prosty: wybierasz maszyny wirtualne, które chcesz chronić, definiujesz miejsce docelowe kopii zapasowej , wybierasz zasady (częstotliwość, typ kopii zapasowej, retencję itp.) i uruchamiasz zadanie. Celem jest szybkie przywrócenie całej maszyny , w przypadku awarii sprzętu lub uszkodzenia dysku RAW, na tym samym węźle lub na innym hoście Proxmox.

Co więcej, Vinchin zazwyczaj oferuje bezpłatne okresy próbne , pozwalające ocenić integrację z infrastrukturą przed podjęciem decyzji o pełnym wdrożeniu. W środowiskach, w których dostępność ma kluczowe znaczenie, połączenie Proxmox z solidnym rozwiązaniem do tworzenia kopii zapasowych jest niemal obowiązkowe, zwłaszcza w przypadku dysków RAW przechowujących bardzo wrażliwe dane.

Urządzenia RAW dla Oracle RAC w systemie Linux

W środowiskach baz danych Oracle RAC zarządzanie współdzieloną pamięcią masową zawsze było kwestią wrażliwą. Chociaż większość dystrybucji Linuksa zawiera Logical Volume Manager (LVM) , nie wszystkie obsługują klastrowanie LVM w sposób, który Oracle uznaje za odpowiedni dla RAC. Dlatego historycznie, dedykowane urządzenia RAW były często używane do obsługi krytycznych komponentów.

Aby skonfigurować tego typu środowisko, najpierw instaluje się dyski współdzielone widoczne dla wszystkich węzłów (na przykład dyski prezentowane przez macierz pamięci masowej wielu serwerom fizycznym lub maszynom wirtualnym). Po rozpoznaniu, system jest w razie potrzeby restartowany, a nazwy urządzeń są identyfikowane za pomocą narzędzi takich jak:

/sbin/fdisk -l

Za pomocą fdisk (lub innych nowoczesnych narzędzi, takich jak parted) tworzysz odpowiednie partycje na każdym dysku: wyświetlasz tabele partycji za pomocą polecenia p, tworzysz nowe za pomocą n i zapisujesz zmiany za pomocą w. Każda z tych partycji zostanie później skojarzona z konkretnym urządzeniem.

Kojarzenie partycji z urządzeniami RAW w systemie Linux

Następnym krokiem jest sprawdzenie, czy w systemie istnieją już urządzenia surowe . Można to zrobić za pomocą:

/usr/bin/raw -qa

Tradycyjne urządzenia RAW stosują konwencję nazewnictwa typu /dev/raw/rawn , gdzie n jest liczbą całkowitą. Każde z nich można powiązać z partycją dysku, dzięki czemu Oracle (lub inne aplikacje) zawsze działają z tymi samymi, stabilnymi nazwami.

Powiązanie jest definiowane w pliku konfiguracyjnym /etc/sysconfig/rawdevices , gdzie dla każdej utworzonej partycji dodawany jest jeden wiersz. Na przykład:

/dev/raw/raw1 /dev/sda1

W tym pliku należy zachować ostrożność i używać urządzeń surowych, które nie są jeszcze używane , aby uniknąć konfliktów. Po zdefiniowaniu powiązań, właściciel, grupa i uprawnienia są dostosowywane zgodnie z przeznaczeniem każdego urządzenia.

W przypadku urządzenia RAW przeznaczonego na przykład dla Oracle Cluster Registry (OCR) zwykle wykonuje się następujące polecenia:

chown korzeń:dba /dev/raw/rawn
chmod 640 /dev/raw/rawn

W przypadku pozostałych urządzeń RAW, które będą hostować pliki danych lub pliki baz danych , uprawnienia dla użytkownika i grupy Oracle są dostosowywane:

chown oracle:oinstall /dev/raw/rawn
chmod 660 /dev/raw/rawn

Następnie powiązanie zdefiniowane w rawdevices jest stosowane poprzez wykonanie:

/sbin/service rawdevices restart

Dzięki temu każda partycja fizyczna jest powiązana z odpowiadającym jej urządzeniem surowym , gotowym do użycia przez Oracle RAC lub dowolną inną aplikację, która tego wymaga.

Surowy plik mapowania urządzeń dla DBCA

Aby umożliwić Asystentowi Konfiguracji Bazy Danych (DBCA) prawidłową identyfikację urządzenia RAW odpowiadającego danemu typowi pliku danych, powszechną praktyką jest utworzenie pliku mapowania . Proces zazwyczaj wygląda następująco:

1. Utwórz podkatalog w ORACLE_BASE, na przykład:
mkdir -p $ORACLE_BASE/oradata/nazwa bazy danych
2. Dostosuj właściciela i uprawnienia:
chown -R oracle:oinstall $ORACLE_BASE/oradata
chmod -R 775 $ORACLE_BASE/oradata

W katalogu dbname tworzony jest plik dbname_raw.conf zawierający wiersze wskazujące, które urządzenie surowe odpowiada każdej przestrzeni tabel lub ważnemu plikowi, na przykład:

SYSTEM=/dev/raw/raw1
SYSAUX=/dev/raw/raw2
TEMP=/dev/raw/raw3

Na koniec zmienna środowiskowa DBCA_RAW_CONFIG jest ustawiana tak, aby wskazywała na ten plik, dzięki czemu DBCA może go odczytać podczas tworzenia bazy danych i przypisać każdy komponent do właściwego urządzenia RAW.

Urządzenia i partycje RAW w systemie SUSE Linux Micro z systemem Combustion

SUSE Linux Micro, ukierunkowany na niezmienne i konteneryzowane wdrożenia, jest często dystrybuowany w postaci obrazów RAW z domyślnym schematem partycjonowania . Aby dostosować ten schemat, przenieść katalogi takie jak /home na inny dysk lub dodać nowe partycje, do gry wchodzi Combustion, system konfiguracji pierwszego uruchomienia.

Combustion korzysta z pliku o nazwie `script` , który zawiera polecenia wykonywane w powłoce `transactional-update` podczas pierwszego uruchomienia. Za pomocą tego skryptu można tworzyć dodatkowe partycje, modyfikować `initramfs`, definiować użytkowników, konfigurować sieć, dodawać klucze SSH , instalować pakiety i wiele więcej, bez konieczności ręcznej ingerencji w system po instalacji.

Na tych obrazach, /etc jest montowany za pomocą overlayFS , a górna warstwa znajduje się na przykład w /var/lib/overlay/1/etc/. Podwoluminy montowane domyślnie są rozpoznawane przez opcje takie jak x-initrd.mount w pliku /etc/fstab. Aby zmodyfikować pliki na podwoluminie, który nie jest montowany domyślnie , należy najpierw zadeklarować jego montowanie podczas rozruchu.

Aby skonfigurować sieć przy pierwszym uruchomieniu, Combustion pozwala dodać instrukcję przekazującą parametr `rd.neednet=1` do `dracut`, wymuszając konfigurację sieci (zwykle przez DHCP) podczas `initramfs`. Jeśli potrzebujesz statycznej konfiguracji sieci, musisz użyć sekcji `changes` w `initramfs`, aby napisać własne pliki NetworkManager lub podobne.

Przykład pracy z partycjami i /home w systemie SUSE Linux Micro

Typowym scenariuszem jest przeniesienie zawartości katalogu /home na inną partycję , na przykład na drugi dysk, taki jak /dev/vdb. W skrypcie Combustion można zdefiniować nowy schemat partycjonowania GPT z jedną partycją dla /dev/vdb za pomocą sfdisk, a następnie sformatować ją w systemie Btrfs lub wybranym systemie plików.

Ponieważ polecenie sfdisk może zająć trochę czasu, warto dodać krótką instrukcję sleep po jego uruchomieniu, aby upewnić się, że tablica partycji jest w pełni zapisana przed kontynuowaniem skryptu. Następnie sformatuj nową partycję, utwórz nowy punkt montowania, przenieś całą zawartość katalogu /home do nowej lokalizacji i dostosuj plik /etc/fstab.

Proces polega na usunięciu starego wpisu /home z pliku /etc/fstab (jeśli istnieje) i utworzeniu nowego wpisu wskazującego na nowe urządzenie. W ten sposób przy następnym uruchomieniu system automatycznie zamontuje nowo utworzoną partycję jako /home, pozostawiając resztę obrazu RAW z oryginalnym podziałem na partycje.

Dodatkowo Combustion służy do innych ważnych zadań: definiowania użytkowników innych niż root (na przykład dla usług takich jak Cockpit), ustawiania hasła roota przy użyciu skrótów generowanych przez openssl passwd -6, dodawania publicznych kluczy SSH do katalogu ~/.ssh/authorized_keys, włączania usług (systemctl enable), a nawet instalowania dodatkowych pakietów, takich jak vim, podczas pierwszego uruchomienia.

W każdym przypadku zaleca się zadbanie o to, aby wszystkie procesy uruchomione w tle (np. tee lub podobne) zakończyły się przed zakończeniem wykonywania skryptu. W tym celu należy dodać na końcu instrukcję, która czeka na zakończenie tych procesów, aby uniknąć niekompletnych konfiguracji.

Odzyskiwanie maszyn wirtualnych z istniejących dysków RAW

Typowym scenariuszem w środowiskach wirtualizacji jest posiadanie nienaruszonych dysków RAW lub LVM, ale utrata konfiguracji maszyn wirtualnych . Może się to zdarzyć na przykład, gdy dysk hostujący hiperwizor (taki jak dysk SSD z Proxmox) ulegnie awarii, ale pamięć masowa, w której znajdowały się dyski maszyn wirtualnych (wielodyskowa macierz RAID), przetrwa.

W takiej sytuacji, po ponownej instalacji hiperwizora (na przykład Proxmox) na nowym dysku SSD, pierwszą rzeczą, jaką należy zrobić, jest sprawdzenie, czy automatycznie wykrywa on wolumin RAID lub dysk . Jeśli system widzi RAID i możesz wyświetlić listę woluminów lub plików RAW na dysku, jesteś na dobrej drodze: dane nadal tam są; wystarczy je ponownie podłączyć do nowych maszyn wirtualnych.

W takich przypadkach wiele osób pomija „magiczną” opcję „ponownej rejestracji wszystkich maszyn wirtualnych” z tych dysków. W zależności od systemu, taki bezpośredni przycisk może nie być dostępny i konieczne może być ręczne utworzenie nowych maszyn wirtualnych i podłączenie każdego dysku RAW lub LVM do odpowiedniej maszyny wirtualnej.

Sztuką jest zdefiniowanie parametrów w nowej maszynie wirtualnej podobnych do oryginalnych: ten sam typ BIOS-u/UEFI, ten sam kontroler dysku (SCSI, VirtIO, SATA…), podobna konfiguracja sieciowa itd. Następnie, zamiast tworzyć nowy dysk, należy wskazać istniejący wolumin RAW lub LVM . Jeśli system operacyjny na dysku nie został uszkodzony, maszyna wirtualna powinna uruchomić się tak, jakby nic się nie stało.

To samo dotyczy innych hiperwizorów: jeśli utracisz hosta klastra, ale zachowasz woluminy LVM lub LUN z surowymi dyskami, możesz ponownie zarejestrować lub utworzyć maszyny wirtualne i bezpośrednio ponownie wykorzystać te urządzenia jako dyski, bez konieczności przywracania pełnych kopii zapasowych (choć zawsze zaleca się posiadanie kopii zapasowych na wypadek, gdyby coś poszło nie tak).

Wykorzystanie obrazów RAW w analizie kryminalistycznej i migracjach między hiperwizorami

W dziedzinie informatyki śledczej i audytów bezpieczeństwa bardzo często otrzymuje się kompletne maszyny wirtualne w formacie VMware do analizy. Jeśli Twoim głównym narzędziem nie jest VMware lub chcesz przeanalizować dane za pomocą specjalistycznych pakietów oprogramowania do analizy śledczej, zazwyczaj znacznie wygodniej jest pracować z plikiem RAW niż z plikiem VMDK.

Praktycznym rozwiązaniem, jak już wspomnieliśmy, jest użycie VirtualBox i narzędzia VBoxManage do konwersji obrazu VMDK do pliku dd/RAW . Po konwersji można zamontować obraz do odczytu w systemie Linux, otworzyć go za pomocą narzędzi analitycznych, a nawet używać jako dysku w innych hiperwizorach obsługujących pliki RAW.

Należy pamiętać, że gdy oryginalny dysk jest dynamiczny, ostateczny wynik w formacie RAW zajmie maksymalną ilość miejsca na dysku , a nie faktycznie wykorzystaną przestrzeń. Dlatego, jeśli VMDK reprezentuje dysk 500 GB, plik RAW będzie zajmował zazwyczaj 500 GB, mimo że tylko 50 GB zostanie wykorzystane wewnętrznie. Dlatego tak ważne jest staranne zaplanowanie miejsca na dysku docelowym przed konwersją.

Dobrą wiadomością jest to, że mając plik RAW, opcje się mnożą: możesz go użyć jako źródła migracji do Proxmox , importując go za pomocą qm importdisk, analizować go kawałek po kawałku, aby uzyskać dowody, a nawet ponownie zapisać zmiany, jeśli przeprowadzasz testy laboratoryjne.

Korzystanie z urządzeń i obrazów RAW w maszynach wirtualnych oferuje szeroki wachlarz możliwości: bezpośredni dostęp do jednostek LUN dla klastrów, ponowne wykorzystanie istniejących dysków, migracje międzyplatformowe, analizę kryminalistyczną i zaawansowaną personalizację systemu . Wymaga to jednak ostrożności, dokładnej dokumentacji typu urządzenia i niezawodnych kopii zapasowych, ponieważ nie ma tak silnej siatki bezpieczeństwa, jak w przypadku prostego pliku dysku wirtualnego, który można skopiować i wkleić.