Cara menggunakan peranti RAW dalam mesin maya

Apabila menggunakan virtualisasi lanjutan, terdapat satu tahap di mana imej cakera maya biasa (VDI, VMDK, QCOW2, dll.) gagal. Di sinilah peranti RAW yang berkaitan secara langsung dengan mesin maya memainkan peranan, sesuai untuk memaksimumkan prestasi storan atau menggunakan semula cakera dan partition sedia ada tanpa perlu menyalinnya ke format lain.

Konfigurasi jenis ini digunakan secara meluas dalam persekitaran seperti VirtualBox, VMware dan Proxmox , kluster Oracle RAC dan makmal forensik . Walaupun ia mungkin kelihatan agak menakutkan pada mulanya, jika anda memahami apa yang anda lakukan, anda boleh mendapat banyak manfaat daripadanya. Sepanjang artikel ini, kita akan melihat secara terperinci cara menggunakan peranti RAW dalam mesin maya merentasi pelbagai hipervisor dan senario dunia sebenar , kelebihan yang ditawarkannya dan langkah berjaga-jaga yang perlu anda ambil untuk mengelakkan kerosakan data.

Apakah peranti RAW dan mengapa menggunakannya dalam mesin maya

Peranti RAW pada asasnya merupakan titik akses langsung dan tidak terganggu kepada cakera fizikal, partition tertentu, volum LVM atau LUN yang dibentangkan daripada tatasusunan SAN. Ini bukan fail cakera maya, tetapi peranti itu sendiri seperti yang dilihat oleh sistem pengendalian hos.

Apabila bekerja dengan cakera maya standard, hipervisor menyimpan data dalam fail .vdi, .vmdk, .qcow2, .raw, dsb. dalam sistem fail (VMFS, ext4, XFS, ZFS, dsb.). Walau bagaimanapun, dengan peranti RAW, VM mengakses secara langsung blok storan asas, sama ada partition setempat, volum LVM, LUN iSCSI/Fibre Channel atau keseluruhan pemacu cakera yang lain.

Pendekatan ini menawarkan beberapa kelebihan: pengurangan overhed, akses perkakasan hampir asli dan keupayaan untuk menggunakan semula cakera sedia ada tanpa penukaran. Dalam persekitaran kluster, ia juga membolehkan berbilang mesin maya mengakses LUN yang sama dan mengurus akses kongsi daripada sistem pengendalian tetamu atau perisian kluster.

Walau bagaimanapun, menggunakan peranti RAW bukanlah sesuatu yang ajaib: ia melibatkan pengguguran (bergantung pada mod) beberapa ciri lapisan virtualisasi , seperti snapshot tertentu atau pengklonan mudah, dan memerlukan lebih banyak penjagaan untuk mengelakkan penulisan ganti cakera yang salah. Itulah sebabnya sangat penting untuk memahami dengan tepat apa yang dilakukan oleh setiap hipervisor dengan jenis pemetaan ini.

Menggunakan peranti RAW dalam VirtualBox

VirtualBox, secara lalai, mencipta mesin maya dalam fail cakera seperti .vdi atau .vmdk; untuk arahan tentang cara mengurusnya, lihat arahan dan contoh VirtualBox . Walau bagaimanapun, ia juga membolehkan anda menggunakan peranti hos mentah: keseluruhan cakera, partition tertentu atau volum LVM. Ini sangat berguna jika anda mahu VM berjalan pada cakera yang telah dikonfigurasikan terlebih dahulu atau jika anda memerlukan prestasi maksimum tanpa melalui lapisan fail.

Ideanya mudah: daripada mencipta cakera maya baharu, anda memberitahu VirtualBox untuk "membungkus" peranti fizikal dan membentangkannya ke mesin maya seolah-olah ia cakera lain. Pembungkusan ini dilakukan menggunakan fail deskriptor kecil yang menunjukkan peranti RAW sebenar (contohnya, /dev/sdb atau /dev/mapper/vgdatos-lvvm1).

Pendekatan ini juga berguna dalam kes di mana anda mempunyai sistem pengendalian yang telah dipasang pada cakera fizikal atau LVM dan ingin butnya dalam VirtualBox VM sambil mengekalkan struktur asal . Atau apabila anda ingin menggunakan partition tertentu untuk pengujian tanpa menjejaskan seluruh cakera.

Tambahan pula, VirtualBox membolehkan anda bekerja dengan format RAW dengan cara lain: dengan menggunakan alat VBoxManage untuk menukar imej daripada hipervisor lain kepada RAW. Ini sering dilihat dalam senario analisis forensik, di mana penting untuk mempunyai dump jenis dd yang mengandungi semua bait cakera asal.

Tukar cakera VMDK kepada format RAW dengan VBoxManage

Satu situasi yang sangat biasa berlaku ialah menerima mesin maya VMware dalam format VMDK dan ingin menganalisis cakera tersebut dengan alat forensik seperti FTK, Autopsy atau yang serupa . Dalam kes ini, biasanya lebih baik menukar imej kepada fail RAW biasa (seperti dd) daripada bekerja secara langsung dengan VMDK.

VirtualBox merangkumi arahan `VBoxManage clonehd` , yang membolehkan anda mengklon dan memformat semula cakera. Arahan biasa untuk menukar daripada VMDK kepada RAW akan kelihatan seperti ini:

VBoxManage clonehd source_file.vmdk destination_file.dd –format mentah

Adalah dinasihatkan untuk menggunakan laluan mutlak bagi mengelakkan masalah, terutamanya jika anda bekerja dengan berbilang cakera dan direktori. Semasa penukaran, VBoxManage mengimbas semua blok VMDK dan menyalinnya tepat ke fail RAW baharu. Jika VMDK dinamik, perlu diingat bahawa imej RAW yang terhasil mungkin akan mengambil lebih banyak ruang pada sistem fail destinasi.

Adalah penting untuk memastikan anda mempunyai ruang kosong yang mencukupi pada pemacu tempat anda akan menyimpan fail RAW, atau anda akan menghadapi ralat pada pertengahan penukaran. Setelah proses selesai, anda akan mempunyai fail dalam format dd standard, yang boleh anda gunakan dengan mudah dalam suite analisis atau memetakan daripada hipervisor lain.

Pemetaan Peranti Mentah (RDM) dalam VMware vSphere/ESXi

Dalam ekosistem VMware, cara klasik untuk memberikan mesin maya akses terus kepada LUN fizikal adalah melalui Pemetaan Peranti Mentah (RDM) . Teknik ini digunakan terutamanya apabila bekerja dengan tatasusunan storan iSCSI atau Fibre Channel dan anda memerlukan VM untuk melihat kelantangan seolah-olah ia disambungkan terus ke sistem.

Daripada mencipta cakera maya dalam stor data VMFS, RDM mencipta fail pemetaan khas pada volum VMFS yang bertindak sebagai pautan simbolik kepada LUN fizikal. Dari perspektif VM, fail ini muncul sebagai cakera lain, tetapi pada hakikatnya, akses dialihkan ke peranti storan mentah.

Pendekatan ini membolehkan anda mengekalkan beberapa kelebihan VMFS (seperti pengurusan berpusat dan beberapa kawalan kebenaran), manakala I/O cakera dilakukan secara langsung terhadap LUN . Ia amat berguna dalam persekitaran kluster di mana beberapa mesin maya berkongsi storan dan memerlukan sistem tetamu untuk mengurus penguncian, atau untuk aplikasi yang memerlukan kawalan SCSI yang sangat halus.

Apabila anda mengkonfigurasi RDM, VMware memberi anda pilihan antara dua mod: mod keserasian maya dan mod keserasian fizikal . Pilihan anda akan menentukan ciri VMware yang masih boleh anda gunakan dan tahap akses yang sebenarnya dimiliki oleh VM ke peranti storan.

Mod keserasian: maya vs fizikal

Mod keserasian maya menjadikan RDM berfungsi, dari perspektif VMware, hampir seperti fail cakera maya biasa. Ini bermakna anda masih boleh menggunakan ciri seperti snapshot VM , walaupun storan asasnya ialah LUN mentah. Ia merupakan kompromi yang baik apabila anda mahukan kesederhanaan dan ciri pengurusan tertentu, tetapi tidak memerlukan akses SCSI peringkat rendah.

Mod keserasian fizikal , sebaliknya, memberikan VM akses langsung kepada peranti SCSI. Ia merupakan pilihan yang sesuai untuk aplikasi yang memerlukan arahan SCSI lanjutan atau pengurusan kendiri berbilang laluan, dan untuk senario kluster tertentu di mana sistem pengendalian tetamu mengendalikan kawalan kelantangan penuh.

Walau bagaimanapun, dalam mod keserasian fizikal, anda akan kehilangan sebahagian daripada keajaiban virtualisasi: tidak semua jenis snapshot dan operasi pengklonan akan tersedia atau akan bertindak sama, kerana VMware mengganggu sesedikit mungkin antara VM dan cakera.

Langkah umum untuk mencipta RDM dalam VMware

Untuk mencipta RDM, aliran dalam klien vSphere biasanya serupa dengan yang berikut. Pertama, pada salah satu mesin maya yang akan menggunakan LUN mentah:

1. Pilih VM dan masukkan "Edit Tetapan" dari menu konteks.
2. Ketik Tambah > Cakera Keras untuk menambah cakera baharu.
3. Pilih pilihan SAN LUN yang dipetakan atau yang setara.
4. Pilih LUN fizikal yang anda ingin petakan dari kokpit.
5. Tentukan di stor data VMFS mana anda ingin menyimpan fail pemetaan.
6. Pilih Fizikal atau Maya sebagai mod keserasian, seperti yang dibincangkan sebelum ini.
7. Pengawal SCSI baharu akan dicipta untuk cakera RDM, memilih Nod Peranti Maya baharu (contohnya SCSI 3:0) berbeza daripada cakera utama VM.

Dalam mesin maya lain yang juga akan menggunakan LUN kongsi yang sama, prosedurnya adalah serupa tetapi dengan satu perbezaan utama: bukannya mencipta RDM baharu, RDM yang sedia ada dalam stor data akan digunakan semula.

Dalam VM tambahan ini:

1. Buka semula Edit Tetapan dalam VM.
2. Ketik Tambah > Cakera Keras.
3. Pilih pilihan Gunakan Cakera Sedia Ada untuk menggunakan semula fail RDM yang telah dibuat.
4. Pilih fail pemetaan yang sama seperti dalam langkah pertama.
5. Konfigurasikan pengawal SCSI dan nod peranti baharu sama seperti dalam VM pertama, dengan mematuhi cadangan VMware untuk kluster.

Dengan cara ini, beberapa mesin maya boleh mengakses LUN yang sama dalam bentuk mentah , meninggalkan kawalan serentak dan akses serentak kepada sistem pengendalian tetamu atau perisian kluster.

Imej cakera Proxmox VE dan RAW untuk mesin maya

Proxmox VE ialah platform virtualisasi sumber terbuka yang komprehensif yang membolehkan anda mengurus kedua-dua mesin maya KVM dan bekas LXC. Salah satu kelebihan utamanya ialah fleksibilitinya dalam mengendalikan cakera mentah , sama ada menciptanya dari awal atau mengimportnya daripada persekitaran lain dan mengaitkannya dengan VM sedia ada.

Cakera RAW, dalam konteks ini, ialah fail yang mengandungi salinan bait demi bait cakera fizikal atau partition . Ia tidak menggabungkan sebarang pemampatan atau ciri tambahan; ia hanya mengandungi semua bait peranti mengikut susunan. Atas sebab ini, ia merupakan format yang sangat serasi dan mudah untuk memindahkan mesin maya antara hipervisor atau memulihkan sandaran dengan transformasi yang minimum.

Dalam Proxmox, anda boleh mencipta imej RAW anda sendiri dengan alatan seperti vmdebootstrap dan mengimport RAW yang telah dijana (cth., dd dumps, penukaran daripada VBoxManage atau output daripada hypervisor lain) dan memasangnya sebagai cakera dalam mesin maya.

Cipta imej cakera RAW dengan vmdebootstrap

Satu cara yang sangat praktikal untuk menyediakan imej RAW untuk Proxmox adalah dengan menggunakan utiliti vmdebootstrap , yang mengautomasikan penciptaan sistem asas dalam fail imej. Alat ini mengendalikan pembahagian, pemformatan , pemasangan sistem, konfigurasi GRUB dan penambahan beberapa pakej asas.

Contoh tipikal arahan untuk menjana imej RAW dengan konfigurasi minimum mungkin termasuk pilihan seperti:

vmdebootstrap –verbose –saiz 10GiB –konsol-siri –grub –tiada-extlinux –pakej openssh-server –pakej avahi-daemon –pakej qemu-guest-agent –nama-host vm600 –enable-dhcp –customize=./copy_pub_ssh.sh –sparse –imej vm600.raw

Dalam arahan jenis ini, anda menentukan parameter seperti saiz cakera, pakej yang hendak dipasang, nama hos VM atau pengaktifan konsol bersiri . Setelah selesai, anda akan mempunyai fail vm600.raw yang mengandungi sistem Linux yang berfungsi sepenuhnya , sedia untuk diimport ke dalam Proxmox sebagai cakera VM.

Cipta mesin maya dan kaitkan cakera RAW dalam Proxmox

Langkah seterusnya ialah mencipta mesin maya kosong dalam Proxmox dan kemudian mengimport fail RAW ke storan yang dikonfigurasikan. Untuk mencipta VM, anda boleh menggunakan arahan `qm create` , menentukan ID VM, antara muka rangkaian dan jenis pengawal cakera.

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

Di sini kami menunjukkan, sebagai contoh, bahawa kami mahu VM mempunyai ID 600, menggunakan VirtIO untuk rangkaian dengan jambatan vmbr0, untuk boot dari scsi0 dengan pengawal virtio-scsi-pci , dan sistem pengendaliannya ialah Linux moden (l26).

Seterusnya, kita import imej RAW ke dalam storan Proxmox menggunakan qm importdisk :

qm importdisk 600 vm600.raw pvedir

Dalam arahan ini, 600 ialah ID VM, vm600.raw ialah laluan ke fail imej dan pvedir ialah nama storan yang ditakrifkan dalam Proxmox (anda boleh menyemaknya dengan status pvesm). Setelah import selesai, anda akan melihat cakera disenaraikan sebagai unused0 atau serupa dalam konfigurasi VM.

Agar VM benar-benar menggunakan cakera itu, ia perlu dikaitkan dengan pengawal , contohnya SCSI:

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

Oleh itu, cakera RAW yang diimport dipautkan ke peranti scsi0 VM. Akhir sekali, mulakan mesin dengan `qm start 600` dan lengkapkan konfigurasi dari konsol, sama seperti yang anda lakukan dengan mana-mana VM lain.

Muat naik dan import imej RAW yang besar ke Proxmox

Apabila bekerja dengan fail RAW yang besar, memuat naiknya ke Proxmox melalui antara muka web mungkin tidak praktikal atau mustahil. Dalam kes sedemikian, adalah disyorkan untuk menggunakan scp, rsync atau alat yang serupa untuk menyalin imej ke nod Proxmox atau storan kongsi sebelum menjalankan `qm importdisk`.

Sebaik sahaja fail berada pada hos, alirannya adalah serupa dengan yang diterangkan di atas: cipta atau pilih VM, import cakera RAW ke storan dan kaitkannya sebagai peranti (scsi0, sata0, dll.), tentukan jenis pengawal yang sesuai mengikut sistem pengendalian tetamu.

Pendekatan yang sama ini berfungsi untuk memindahkan VM dari platform lain : anda menukar cakera kepada RAW (jika belum lagi), salinnya ke nod Proxmox, importnya dengan qm importdisk dan akhirnya laraskan konfigurasi VM ( pemacu rangkaian , pengawal, susunan but, dll.) sehingga ia berfungsi dengan betul.

Sandaran VM dengan cakera RAW dalam Proxmox

Apabila bekerja dengan imej cakera RAW dalam Proxmox, anda tidak boleh melupakan tentang sandaran dan pemulihan bencana . Selain sandaran terbina dalam Proxmox, terdapat penyelesaian pihak ketiga seperti Vinchin Backup & Recovery yang disepadukan dengan hypervisor dan membolehkan pengurusan sandaran lanjutan.

Vinchin menawarkan penyelesaian sandaran yang direka khusus untuk persekitaran maya, termasuk Proxmox VE . Ia menyokong sandaran penuh dan tambahan mesin maya, serta pemulihan berbutir atau penuh. Ini amat berguna apabila bekerja dengan VM yang but daripada imej RAW, LVM atau ZFS yang diimport , kerana alat ini mengatur keseluruhan proses tanpa anda perlu berurusan dengan format yang berbeza.

Aliran kerja biasanya mudah: anda memilih VM yang ingin anda lindungi, menentukan destinasi sandaran , memilih dasar (frekuensi, jenis sandaran, pengekalan, dll.) dan menjalankan tugas tersebut. Matlamatnya ialah, sekiranya berlaku kegagalan perkakasan atau kerosakan cakera RAW, anda boleh memulihkan keseluruhan mesin dengan cepat , sama ada pada nod yang sama atau pada hos Proxmox yang lain.

Tambahan pula, Vinchin biasanya menawarkan tempoh percubaan percuma , yang membolehkan anda menilai penyepaduannya dengan infrastruktur anda sebelum membuat komitmen sepenuhnya untuk menerima pakai. Dalam persekitaran di mana ketersediaan adalah penting, menggabungkan Proxmox dengan penyelesaian sandaran yang mantap hampir wajib, terutamanya apabila bekerja dengan cakera RAW yang menyimpan data yang sangat sensitif.

Peranti RAW untuk Oracle RAC pada Linux

Dalam persekitaran pangkalan data Oracle RAC, pengurusan storan kongsi sentiasa menjadi isu sensitif. Walaupun kebanyakan pengedaran Linux termasuk Pengurus Kelantangan Logikal (LVM) , tidak semua menyokong LVM berkelompok dengan cara yang dianggap sah oleh Oracle untuk RAC. Oleh itu, dari segi sejarah, peranti RAW khusus sering digunakan untuk komponen kritikal.

Untuk menyediakan persekitaran jenis ini, cakera kongsi yang boleh dilihat oleh semua nod dipasang terlebih dahulu (contohnya, cakera yang dibentangkan oleh tatasusunan storan kepada berbilang pelayan fizikal atau VM). Setelah dikenal pasti, sistem akan dimulakan semula jika perlu dan nama peranti dikenal pasti menggunakan alat seperti:

/sbin/fdisk -l

Menggunakan fdisk (atau alat moden lain seperti parted), anda mencipta partition yang sesuai pada setiap cakera: anda menyenaraikan jadual partition dengan arahan p, mencipta yang baharu dengan n dan menulis perubahan dengan w. Setiap partition ini kemudiannya akan dikaitkan dengan peranti mentah tertentu.

Mengaitkan partition dengan peranti RAW dalam Linux

Langkah seterusnya adalah untuk menyemak sama ada peranti mentah sudah wujud dalam sistem . Ini boleh dilakukan menggunakan:

/usr/bin/raw -qa

Peranti RAW tradisional mengikuti konvensyen penamaan jenis /dev/raw/rawn , dengan n ialah integer. Setiap satu daripada ini boleh dipautkan ke partition cakera, supaya Oracle (atau aplikasi lain) sentiasa berfungsi dengan nama stabil yang sama.

Perkaitan ditakrifkan dalam fail konfigurasi /etc/sysconfig/rawdevices , dengan menambah satu baris untuk setiap partition yang dicipta. Contohnya:

/dev/mentah/mentah1 /dev/sda1

Dalam fail ini, langkah berjaga-jaga perlu diambil untuk menggunakan peranti mentah yang belum digunakan bagi mengelakkan konflik. Sebaik sahaja perkaitan ditakrifkan, pemilik, kumpulan dan kebenaran akan diselaraskan mengikut tujuan penggunaan setiap peranti.

Untuk peranti RAW yang bertujuan untuk Oracle Cluster Registry (OCR) , sebagai contoh, arahan seperti berikut biasanya dilaksanakan:

chown akar:dba /dev/mentah/mentah
chmod 640 /dev/mentah/mentah

Untuk peranti RAW yang selebihnya yang akan mengehoskan fail data atau fail pangkalan data , kebenaran dilaraskan untuk pengguna dan kumpulan Oracle:

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

Selepas ini, pengikatan yang ditakrifkan dalam rawdevices digunakan dengan melaksanakan:

/sbin/perkhidmatan peranti mentah dimulakan semula

Oleh itu, setiap partition fizikal dikaitkan dengan peranti mentah yang sepadan , sedia untuk digunakan oleh Oracle RAC atau sebarang aplikasi lain yang memerlukannya.

Fail pemetaan peranti mentah untuk DBCA

Untuk membolehkan Pembantu Konfigurasi Pangkalan Data (DBCA) mengenal pasti peranti RAW yang sepadan dengan setiap jenis fail data dengan betul, amalan biasa adalah untuk mencipta fail pemetaan . Prosesnya biasanya seperti ini:

1. Cipta subdirektori di bawah ORACLE_BASE, contohnya:
mkdir -p $ORACLE_BASE/oradata/dbname
2. Laraskan pemilik dan kebenaran:
chown -R oracle:oinstall $ORACLE_BASE/oradata
chmod -R 775 $ORACLE_BASE/oradata

Dalam direktori dbname, fail dbname_raw.conf dicipta dengan baris yang menunjukkan peranti mentah yang sepadan dengan setiap ruang jadual atau fail penting, contohnya:

SISTEM=/dev/mentah/mentah1
SYSAUX=/dev/mentah/mentah2
SUHU=/pembangunan/mentah/mentah3

Akhir sekali, pembolehubah persekitaran DBCA_RAW_CONFIG ditetapkan untuk menunjuk ke fail tersebut, supaya DBCA boleh membacanya semasa penciptaan pangkalan data dan menetapkan setiap komponen kepada peranti RAW yang betul.

Peranti dan partition RAW dalam SUSE Linux Micro dengan Pembakaran

SUSE Linux Micro, yang ditujukan kepada penggunaan yang tidak boleh diubah dan disimpan dalam bekas, sering diedarkan sebagai imej RAW dengan skema pembahagian lalai . Apabila anda ingin menyesuaikan skema tersebut, memindahkan direktori seperti /home ke cakera lain atau menambah pembahagian baharu, Combustion, sistem konfigurasi but pertama, akan dimainkan.

Combustion menggunakan fail bernama `script` , yang mengandungi arahan yang dilaksanakan dalam shell `transactional-update` semasa but pertama. Melalui skrip ini, anda boleh mencipta partition tambahan, mengubah suai `initramfs`, mentakrifkan pengguna, mengkonfigurasi rangkaian, menambah kekunci SSH , memasang pakej dan banyak lagi, tanpa menyentuh sistem secara manual selepas pemasangan.

Dalam imej ini, /etc di-mount menggunakan overlayFS , dengan lapisan atas terletak, contohnya, di /var/lib/overlay/1/etc/. Subvolume yang di-mount secara lalai dikenali oleh pilihan seperti x-initrd.mount dalam /etc/fstab. Jika anda ingin mengubah suai fail pada subvolume yang tidak di-mount secara lalai , anda mesti mengisytiharkannya terlebih dahulu sebagai di-mount semasa but.

Untuk mengkonfigurasi rangkaian pada but pertama, Combustion membolehkan anda menambah arahan yang menghantar parameter `rd.neednet=1` kepada `dracut`, memaksa konfigurasi rangkaian (biasanya melalui DHCP) semasa `initramfs`. Jika anda memerlukan konfigurasi rangkaian statik, anda perlu menggunakan bahagian perubahan dalam `initramfs` untuk menulis fail NetworkManager anda sendiri atau yang serupa.

Contoh bekerja dengan partition dan /home dalam SUSE Linux Micro

Satu senario biasa ialah memindahkan kandungan /home ke partition yang berbeza , contohnya, cakera kedua seperti /dev/vdb. Dalam skrip Combustion, anda boleh mentakrifkan skema partition GPT baharu dengan partition tunggal untuk /dev/vdb menggunakan sfdisk, dan kemudian memformatkannya dalam Btrfs atau sistem fail pilihan anda.

Memandangkan arahan sfdisk mungkin mengambil sedikit masa, adalah idea yang baik untuk menambah pernyataan tidur pendek selepas menjalankannya, memastikan jadual partition ditulis sepenuhnya sebelum meneruskan skrip. Seterusnya, formatkan partition baharu, cipta titik pemasangan baharu, alihkan sebarang kandungan /home ke lokasi baharunya dan laraskan /etc/fstab.

Proses ini melibatkan pengalihan keluar entri /home lama daripada /etc/fstab (jika wujud) dan mencipta entri baharu yang menghala ke peranti baharu. Dengan cara ini, pada but seterusnya, sistem akan memasang partition yang baru dibuat secara automatik sebagai /home, meninggalkan imej RAW yang lain dengan partition asalnya.

Di samping itu, Combustion digunakan untuk tugas penting lain: mentakrifkan pengguna bukan root (contohnya, untuk perkhidmatan seperti Cockpit), menetapkan kata laluan root menggunakan hash yang dijana dengan openssl passwd -6, menambah kunci SSH awam ke direktori ~/.ssh/authorized_keys, mendayakan perkhidmatan (systemctl enable), dan juga memasang pakej tambahan seperti vim semasa but pertama.

Dalam semua kes, adalah dinasihatkan untuk memastikan semua proses yang dilancarkan di latar belakang (cth., tee atau yang serupa) selesai sebelum pelaksanaan skrip tamat, dengan menambah arahan di penghujungnya yang menunggu proses ini selesai bagi mengelakkan konfigurasi yang tidak lengkap.

Memulihkan mesin maya daripada cakera RAW sedia ada

Satu senario biasa dalam persekitaran virtualisasi ialah mempunyai cakera RAW atau LVM yang utuh tetapi kehilangan konfigurasi VM . Contohnya, ini boleh berlaku apabila cakera yang mengehoskan hipervisor (seperti SSD dengan Proxmox) gagal, tetapi storan tempat cakera VM berada (tatasusunan RAID berbilang cakera) kekal.

Dalam situasi seperti ini, selepas memasang semula hipervisor (contohnya, Proxmox) pada SSD baharu, perkara pertama yang perlu dilakukan ialah menyemak sama ada ia mengesan RAID atau volum storan secara automatik . Jika sistem melihat RAID dan anda boleh menyenaraikan volum atau fail cakera RAW, anda berada di landasan yang betul: data masih ada; anda hanya perlu menyambungkannya semula ke VM baharu.

Apa yang ramai orang terlepas pandang dalam kes ini ialah pilihan "ajaib" untuk "mendaftarkan semula semua VM" daripada cakera tersebut. Bergantung pada sistem, mungkin tiada butang langsung sedemikian, dan anda mungkin perlu mencipta mesin maya baharu secara manual dan melampirkan setiap cakera RAW atau LVM ke VM yang sepadan.

Caranya adalah dengan menentukan parameter dalam VM baharu yang serupa dengan yang asal: jenis BIOS/UEFI yang sama, pengawal cakera yang sama (SCSI, VirtIO, SATA…), konfigurasi rangkaian yang serupa, dsb. Kemudian, daripada mencipta cakera baharu, anda menunjuk ke volum RAW atau LVM sedia ada . Jika sistem pengendalian pada cakera tidak rosak, VM sepatutnya boleh but seolah-olah tiada apa yang berlaku.

Perkara yang sama berlaku untuk hipervisor lain: jika anda kehilangan hos kluster tetapi mengekalkan isipadu LVM atau LUN dengan cakera mentah, anda boleh mendaftar semula atau mencipta semula VM dan menggunakan semula peranti tersebut secara langsung sebagai cakera, tanpa perlu memulihkan sandaran penuh (walaupun sentiasa dinasihatkan untuk mempunyai sandaran sekiranya berlaku sesuatu yang tidak kena).

Menggunakan imej RAW dalam analisis forensik dan migrasi antara hipervisor

Dalam bidang forensik dan pengauditan keselamatan, adalah perkara biasa untuk menerima mesin maya lengkap dalam format VMware untuk dianalisis. Jika alat utama anda bukan VMware, atau jika anda ingin memeriksa data dengan suit forensik khusus, biasanya lebih mudah untuk bekerja dengan RAW dump berbanding dengan VMDK.

Penyelesaian praktikal, seperti yang telah kami sebutkan, adalah dengan menggunakan VirtualBox dan alat VBoxManage untuk menukar imej VMDK kepada fail dd/RAW . Selepas penukaran, anda boleh memasang imej ini untuk dibaca dari Linux, membukanya dengan alat analisis atau menggunakannya sebagai cakera dalam hipervisor lain yang menyokong fail RAW.

Penting untuk diingat bahawa apabila cakera asal dinamik, output RAW akhir akan menempati ruang cakera maksimum , bukan ruang sebenar yang digunakan. Oleh itu, jika VMDK mewakili cakera 500 GB, fail RAW cenderung menempati 500 GB, walaupun hanya 50 GB yang akan digunakan secara dalaman. Oleh itu, pentingnya merancang ruang cakera destinasi dengan teliti sebelum penukaran.

Perkara yang baik ialah, sebaik sahaja anda mempunyai fail RAW, pilihan akan berganda: anda boleh menggunakannya sebagai sumber migrasi ke Proxmox dengan mengimportnya dengan qm importdisk, menganalisisnya sedikit demi sedikit untuk mendapatkan bukti, atau menulis perubahan padanya sekali lagi jika anda melakukan ujian makmal.

Menggunakan peranti dan imej RAW dalam mesin maya menawarkan pelbagai kemungkinan: akses langsung kepada LUN untuk kluster, penggunaan semula cakera sedia ada, migrasi merentas platform, analisis forensik dan penyesuaian sistem lanjutan . Walau bagaimanapun, ia memerlukan berhati-hati, dokumentasi jenis peranti yang teliti dan sandaran yang boleh dipercayai, kerana tidak terdapat jaringan keselamatan sebanyak fail cakera maya mudah yang boleh anda salin dan tampal.