生イメージは、次のようにVMDKイメージに変換できますqemu-img
。
qemu-img convert -O vmdk "$_raw" "$_vmdk"
生成されたVMDKイメージのUUIDは、次のように設定できます。
VBoxManage internalcommands sethduuid "$_vmdk" "$_uuid"
変換時にディスクのUUIDを設定する方法はありますかqemu-img
(このソリューションがFreeBSDで動作する場合は良いでしょう)?
答え1
この答えは私の頭からのものです。いいえテスト済みです。テストしてみると、答えを更新してください。
残念ながら、この質問には、私たちがこれを行う理由を説明する文脈はほとんどありません。表面的には以下を参照できます。qemu-img答えは「いいえ」です。
しかし、それは退屈でしょう。代わりに、いくつかの言葉にならない仮定をして実行してみましょう。
説明するソリューションはqemu-img
FreeBSDで可能です。エミュレータ/qemu-utilsvboxmanageは以下から来ています。エミュレータ/仮想ボックス-ose。おそらくそれがあなたがしていることでしょうか?しかし、これがなぜ問題なのかは言っていませんでした(ただ1つのツールを使用したくないのですか?)。
興味深いことに、これはただのヒントです。GUIDパーティションテーブル(GPT)ディスクに。qemu-img
ディスクに何があるかはあまり気にしないでください。しかし、vboxmanage
ヘルパー機能だけで十分です。
ディスクへ
/dev/ada0
したがって、asのフルソースコピー(またはQemuによって作成されたソースファイル)がある場合は、ada0.dd
そのイメージを仮想メモリディスクとして使用できます。
# mdconfig -a -t vnode -u 0 -f /home/johndoe/ada0.dd
/dev/md0
これにより、完全なディスクが提供されます。
これで、すべてがよく見えることを確認できます。
# fdisk /dev/md0
これは前のディスクとまったく同じでなければなりません。
# glabel status
GPTを使用するときは、次のことを好むことができます。gpart
# gpart create -s gpt /dev/md0
UUIDはこのコマンドを使用して自動的に生成されます。実際、パーティションテーブルのエントリに触れるかどうかはわかりません。このような場合は、まずバックアップしてください。たぶんテーブル全体を破壊するかもしれません。作成して復元しますか?ここではいくつかのテストを実行する必要があります。しかし、重要なのは、ドライブへのフルアクセス権があることです。
以下を使用してファイルシステムをマウントできます。この方法しかも
ファイルとして
GUIDパーティションテーブルの回路図を見るとウィキペディアパーティションテーブルヘッダのオフセット56で混合エンディアンディスクGUIDが見つかったと聞きました。
したがって、ディスクイメージをマウントする代わりに、単にバイトの束と考えることができます。 512バイトセクタを使用していると仮定しますが、4Kセクタに合わせて調整する必要があるかもしれません。ヘッダはLBA1にあり、オフセット56に興味がある。したがって、512 + 56 = 568です。
$ hexdump -v -s 568 -n 16 -e '1/1 "%.2x\n"' /home/johndoe/ada0.dd
その後、必要なバイトだけを簡単に変更できます。 Hexdumpでは十分ではありません。見てください。xxd付属編集/vim。ウイデゲン正しいGUIDを生成するのに役立ちます。
このルートに移動する場合は、次の点に注意してください。
- 何かを書く前に、「EFI PART」の署名を確認してスクリプトの弾力性を確保してください。
- また、変更する必要があるヘッダーのセカンダリコピーもあることを覚えておいてください(オフセット32を参照してください)。
これは面白い小さなスクリプトになります。
ストリームメディア
私はあなたが本当に欲しいものが元の生の画像を元の状態に保ち、即座に作業を行うことであるという秘密の疑いがあります。私たちは部分的にxxd
サポートを提供stdin
しstdout
、パイプを介して接続することができます。残念ながら、それはqemu-img
サポートのようには見えませんstdin
。
その後、ディスクにファイルが必要です。実用的な解決策は、元のファイルをバックアップとして保持し、新しいコピーを使用して変更することです。これはディスク容量のコストだけ増加します。
ただし、FreeBSDを使用すると、ディスク容量を節約し、コピーを避けるための非常に高速な方法があります。 ZFSは有利に使用できる。新しいデータセットを作成し、元のイメージファイルをここに配置してからスナップショットを作成します。その後、ファイルを直接変更できますが、変更されたバイト(または変更されたセクタ)にのみ影響します。完了したら、スナップショットをロールバックしてそのセクタをすばやく復元できます。
すべてのスナップショットを撮りたくないので、特定のデータセットを作成します。
# zfs create zroot/rawfiles
必要なデータをここに入れて、/rawfiles
きれいな状態のスナップショットを作成します。
# zfs snapshot zroot/rawfiles@cleanstate
その後、潜在的に大きなイメージファイルで数バイトを変更できます。きれいな状態に戻りたいときにロールバックします。
# zfs rollback zroot/rawfiles@cleanstate
スペース制約がある場合、これは高速で実行可能なオプションです。このようなことをしている場合は、ロールバックを続行する場合は競合状態に注意してください。
これを備えてこれをバックアップとして持っている場合は、別々のデータセットの作成をスキップし、zfs snapshot zroot@hailmary
問題が発生した場合にのみ実行できます。cp /.zfs/snapshot/hailmary/......
手動
画像生成プロセスに影響を与える場合、いくつかの興味深いオプションもあります。
qemu-img
新しい画像を作成し、それをマウントし、GPT(新しいGUIDを含む)を生成するために使用できます。
# qemu-img create -f raw VM10G.raw 10G
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0
しかし、ファイルだけなのでqemu-img
。
# truncate -s 10g VM10G.raw
# mdconfig -a -t vnode -u 0 -f VM10G.raw
# gpart create -s gpt /dev/md0
私はこれをなぜ見せていますか?まあ、多分あなたはこの文脈で何かをしているかもしれません。 FreeBSDには非常に賢いトリックがあります:ムジンガ(1)。
これにより、FreeBSDはディスクイメージを作成し、QCOW、QCOW2、動的VHD、固定VHD、VMDK、RAWをサポートします。つまり、VMDKに直接移動できます。
mkimg -f vmdk -s gpt -b /boot/pmbr -p freebsd-boot:=/boot/gptboot -p freebsd-ufs:=root-file-system.ufs -p freebsd-swap::1G -o gpt.vmdk
この例はFreeBSD中心ですが、rawパーティションを使用しています。したがって、ソース全体のディスクイメージからパーティション専用イメージにソースを変更する場合は、作業パスが必要です。