Clever Geek Handbook

パーティションなしのディスクからのLinux仮想マシンの起動

通常、fdisk / gdiskを使用して、仮想マシンのルートディスクを作成する場合、オペレーティングシステムをホストする単一のパーティションを持つパーティションテーブルが作成されます。 これにより、ハイパーバイザーの側でいくつかの問題が発生します。例：





カーネルを直接ロードすることでパーティションテーブルを削除できますが、この方法は無罪ではありません。 ハイパーバイザーには、ゲストOSを更新するときに最新の状態に保つ必要がある仮想マシンカーネルのイメージが必要です。

EFIとGRUB2を使用して、パーティションのないディスクから起動する代替オプションについて説明します。



libvirt、qemu、kvm、Ubuntuですべてが発生します。



まとめ



以下は、仮想USBディスクからEFIモードで仮想マシンをロードする方法を示しています。仮想USBディスクには、パーティションのないディスクからメニューをロードするように構成されたEFIバージョンのgrubのディレクトリが表示されます。 ふう...さらに途中でいくつかの熊手。

議論されるlibvirtドメインのセットアップ 
<domain type='kvm' id='23'> <name>aster</name> <uuid>d4ee890e-658c-9ff3-6242-9569be3aa154</uuid> <memory unit='KiB'>524288</memory> <currentMemory unit='KiB'>524288</currentMemory> <vcpu placement='static'>1</vcpu> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> <loader>/opt/ovmf/OVMF.fd</loader> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/kvm-spice</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/mapper/ssd-aster--root'/&qt; <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </disk> <disk type='dir' device='disk'> <driver name='qemu'/> <source dir='/var/spool/efi-grub/'/&qt; <target dev='sda' bus='usb'/> <readonly/> <alias name='usb-disk0'/> </disk> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='usb' index='0'> <alias name='usb0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> </domain>




EFI BIOS



そしてここにEFIはありますか？ EFIモードでダウンロードすると、grub-efiを通常のファイルシステムに配置でき、MBRは不要です。 まず、EFIをサポートするqemuのBIOSが必要です。 これはOVMFと呼ばれます 。 ダウンロードしたすべての資産のうち、OVMF.fdのみが必要です（さらに、/ opt / ovmf /にあると想定されます）。 OVMFは、ローダータグを使用してドメインのosセクションに接続されます。 



  <os> <type arch='x86_64' machine='pc-i440fx-1.5'>hvm</type> <loader>/opt/ovmf/OVMF.fd</loader> <boot dev='hd'/> </os>


ブートローダー



これで、仮想マシンを最新の方法でロードできます。 この方法には、ブートローダーが置かれる特別なEFIセクションが必要です。 grub-efiを準備します。 



 mkdir -p /var/spool/efi-grub/efi/boot/ grub-mkimage -O x86_64-efi -d /usr/lib/grub/x86_64-efi/ -o /var/spool/efi-grub/efi/boot/bootx64.efi -p "(hd1)/boot/grub/" part_gpt part_msdos fat ext2 normal chain boot configfile linux multiboot efi_gop efi_uga


ご覧のとおり、作成中のブートローダーの配置と名前にはいくつかの機能があります。 実際には、デフォルトでは、OVMF-BIOSはEFIパーティションから/efi/boot/bootx64.efiファイルをロードしようとします。 これを利用し、そこでgrub-efiをスリップします。これにより、システムの2番目のディスクから/ boot / grub /から構成が取得されます。 後で、このブートローダーは多くの仮想マシンで使用でき、読み取り専用ディスクに接続し、/ boot / grubのあるディスクがシステムの2番目であることが条件になります。



EFIパーティションとレーキ



そのため、ブートローダーを配置するゲスト内にブート可能なEFIパーティションが必要になりました。 小さなディスクを作成し、GPTパーティションテーブルとEFIパーティションをブートローダーに配置できます。 このドライブを読み取り専用モードで接続すると、そのようなドライブを複数の仮想マシンに使用できます。 しかし、熊手があります。 通常のディスクのようにvirtioバスに配置すると、起動時にロードされたシステムではなくEFIシェルに驚かされます。 さらに、このシェルはセクションを確認してコマンド「bootx64.efi」を使用してブートローダーをロードしても問題ありませんが、手がなければフォーカスを合わせることができません。 ここで彼らは詳細に議論し、理由を見つけ、これがOVMFのバグであることに同意します。

したがって、ディスクをIDEバスに接続する必要があります。 これは有効なオプションですが、ドライブを読み取り専用にすることはできません。 ゲスト内でこのディスクに関する衛生状態を観察し、（おそらく）1つのローダーで複数のマシンを起動するというアイデアに別れを告げる必要があります。

より良いオプションがあります。



Qemuでディレクトリをディスクに反映する


Qemuはディレクトリから仮想ディスクを作成できます。 次のようになります。 



  <disk type='dir' device='disk'> <source dir='/var/spool/efi-grub/'/&qt; <target dev='sda' bus='usb'/> <readonly/> </disk>


この場合、MBRのパーティションテーブル、ディレクトリの内容が含まれるFAT16のパーティションを持つディスクがゲストシステムに表示されます。 このディスクには、いくつかの重要な機能があります。接続時には、読み取り専用属性が必要であり、そのパーティションはEFIで要求される0xEFではなく0x06タイプです。 さいわい、USBバスにディスクをハングさせると、このセクションから起動できます。 この場合、OVMF-BIOSは通常のFATパーティションでブートローダーを検索します。



そして、ここには別のレーキがあります。 apparmorが機能し、Ubuntuでデフォルトで機能する場合、額に入れます。

各仮想マシンに対して、libvirtはapparmorプロファイルを作成します。これにより、configで指定されたリソースにのみアクセスできます。 ディレクトリから作成されたディスクに対して間違ったルールが作成されるため、次の行を/etc/apparmor.d/abstractions/libvirt-qemuに追加する必要があります。 



 /var/spool/efi-grub/ r, /var/spool/efi-grub/** r,


重要な注意事項



これで、lvmボリュームに直接ディスクを作成して仮想マシンを作成でき、サイズを簡単かつ安全に変更できます。debootstrapを使用して展開された新しいマシンにブートローダーをインストールする必要はなく、ダンプを使用してルートシステムのバックアップコピーを作成し、単純な復元でそれらを復元できます。



ただし、いくつかの制限があります。 usbおよびideバスOVMF上のディスクは、常に前にvirtioにディスクを配置し、grubでハードコーディングしてメニューとモジュールを2番目のディスクからロードします（最初のディスクはブートローダーのあるディスクです）。 



 grub-mkimage -O x86_64-efi -d /usr/lib/grub/x86_64-efi/ -o /var/spool/efi-grub/efi/boot/bootx64.efi -p "(hd1)/boot/grub/" part_gpt part_msdos fat ext2 normal chain boot configfile linux multiboot efi_gop efi_uga


-pオプション（（hd1）/ boot / grub / "を使用してこれを行いました。 ここで（hd1）は2番目のディスク（それぞれ、最初（hd0））を指します。 virtio以外のディスクをマシンに追加する場合は、このことに留意してください。



また、grubは/ boot / grubルートパーティションから追加のモジュールを動的にロードでき、ゲストシステムは異なる可能性があるため、これらのモジュールのバージョンはEFIパーティションのブートローダーと互換性がない可能性があることに注意してください。 上記の行に名前を追加して必要なモジュールを静的にプッシュすることで、これを取り除くことができます。


More articles:


All Articles