hiroの長い冒険日記

主にコンピュータ周辺の興味を持った内容を綴ります

トップ > 仮想化 > Desktop PC 128GB SSD へ Debian install (Hyper-V Pass through disk) その7 (完)

Desktop PC 128GB SSD へ Debian install (Hyper-V Pass through disk) その7 (完)

仮想化 仮想化-HyperV Linux PC

当日記ではアフィリエイト広告を利用しています

前回までに、物理 SSD に install した Debian64 を仮想ディスクにして、Hyper-V 第一世代(vhd)、第二世代(vhdx、GPT)の仮想マシンで起動する事が出来た。
hiro20180901.hatenablog.com
目的としていたのは

  • 物理 SSD <-> 仮想ディスクを入れ替えて
  • 実PC と仮想マシンのどちらでも起動できる

を確認する事だった。残りは

  1. vhd 仮想ディスクを raw disk image に変換
  2. raw disk image を物理 SSD に書き込む
  3. 実 PC と仮想マシン Path through 接続で物理 SSD から起動

の3点。順次確認した。

vhd 仮想ディスクを raw disk image へ変換

Windows10 Hyper-V 第一世代で使用していた vhd 仮想ディスクを、WSL Ubuntu から Hyper-V 仮想 Ubuntu へ scp した。scp の疑いは晴れているので md5sum による check はなし。後で違いが分かるように qemu を install しておいた。

$ scp ./debian.vhd username@192.168.n.n:/mnt/datahdd/debian_new.vhd

qemu-img を使用して、vhd を raw disk image に変換した。
docs.openstack.org

$ cd /mnt/datahdd/
$ sudo qemu-img convert -f vpc -O raw ./debian_new.vhd ./sdb_new.img

今の PC の CPU能力、SATA HDD の能力だと、変換に約50分必要である...長い。途中、容量不足で各種 img を整理しながら進め、どちらも問題なく終了した。

Hyper-V 仮想 Ubuntu 内の qemu で、vhd から変換した raw disk image から起動できるか確認した。

$ qemu-system-x86_64 -m 1024 /mnt/datahdd/debian_new.vhd
$ qemu-system-x86_64 -m 1024 /mnt/datahdd/sdb_new.img

どちらもOK。無事起動できた。

disk image と 物理 SSD の比較

仮想 Ubuntu に 物理 SSD を Path through 接続し、先ずは raw disk image と容量に差がないかを確認した。
raw disk image:

$ LANG=C sudo fdisk -l /mnt/datahdd/sdb_new.img
Disk /mnt/datahdd/sdb_new.img: 119.2 GiB, 128036536320 bytes, 250071360 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xba8ee247

Device                    Boot     Start       End   Sectors   Size Id Type
/mnt/datahdd/sdb_new.img1 *         2048 241682431 241680384 115.2G 83 Linux
/mnt/datahdd/sdb_new.img2      241684478 250068991   8384514     4G  5 Extended
/mnt/datahdd/sdb_new.img5      241684480 250068991   8384512     4G 82 Linux swap / Solaris

物理 SSD:

$ LANG=C sudo fdisk -l /dev/sdc
Disk /dev/sdc: 119.2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xba8ee247

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sdc1  *         2048 241682431 241680384 115.2G 83 Linux
/dev/sdc2       241684478 250068991   8384514     4G  5 Extended
/dev/sdc5       241684480 250068991   8384512     4G 82 Linux swap / Solaris

1行目を比較すると、raw disk image の方が多い。860,160 bytes (1680 sectors x 512 bytes)。Start Sector、End Sector、Sectors に違いは無い。不思議に思い、取っておいた最初の raw disk image を確認すると物理 SSD と同じ。という事は、raw disk image (original) -> vhd -> raw disk image (convert) の過程で sector が増えている事になる。それじゃあ、vhd はどうなの? と考えて、Windows10 側に取っておいた debian.vhd を起動して確認すると、

# fdisk -l /dev/sda
Disk /dev/sda: 119.2 GiB, 128036536320 bytes, 250071360 sectors
...略...

やはり、vhd にする段階で 1680 sectors だけ増えていた。

仮想ディスク -> 物理 SSD へ書き込み

ググっても良い情報が見つからない(こんな事を考える人はいないのだろうか...)ので、書き込んでみる事にした。Extended partition は 4GB あるし、ここは Linux Swap の領域なので、最悪でも swap が使えない程度で済むだろうという感触もある。device name を間違えないように注意しながら実行した。source が /mnt/datahdd/sdb_new.img、物理 SSD が /dev/sdc。option で status=progress を指定すると進捗が表示されるようになる。

$ sudo dd if=/mnt/datahdd/sdb_new.img of=/dev/sdc status=progress
128024674816 bytes (128 GB, 119 GiB) copied, 11855 s, 10.8 MB/s
dd: '/dev/sdc' に書き込み中です: デバイスに空き領域がありません
250069681+0 レコード入力
250069680+0 レコード出力
128035676160 bytes (128 GB, 119 GiB) copied, 11858.2 s, 10.8 MB/s

やはり書き込む領域が不足していた。bs を指定していないので 512 bytes/record なので、最後の 1 レコードが記録されなかった。vhd にした時に何処で増えているのか...MBR 形式の構造を調べて、binary editor で解析すれば分かるが、今回はそこまでせず。

3時間17分を要した。10.8 MB/s は遅い。bs 大きめにすれば速いのかも。

Hyper-V 仮想マシンに 物理 SSD をPath through 接続して起動

既に物理 SSD Path through で作成していた Hyper-V 仮想マシンで起動してみた...OK、問題なく起動した。swap 領域は実際より不足しているはずだが、 Memory 1024 MB だと swapon されていても swap を使わないので、問題は顕在化していない模様。最初の install 直後の Debian64 には入れていなかった qemu も入っていたので、ちゃんと書き込まれているのが分かる。

実PC から物理 SSD で起動

BIOS で起動順を変更して、実PC で物理 SSD から起動してみた。grab の root fs 指定を UUID に変更してあるので、問題なく起動出来るはず...OK、無事起動できた。

結果

当初に想定していた、物理 SSD と仮想ディスクを入れ直して、実 PC と仮想マシンで起動させる事について、全て確認する事が出来た。

  1. Hyper-V Path through 物理 SSD に Debian64 をinstall し、
  2. 仮想マシンでも実 PC でも起動でき、
  3. 仮想マシンの Ubuntu の dd で Path through 物理 SSD の中身を取り出し
  4. disk image を raw -> vhd に qemu-image で変換し、
  5. qemu から vhd 仮想ディスクで仮想マシンを起動できる事を確認し、
  6. Hyper-V 第一世代(vhd)で仮想マシンを起動できる事を確認し、
  7. vhd -> vhdx、更に MBR -> GPT に変換し、GPT の ESP 領域の Hyper-V Minrosoft UEFI で認識する場所に efi を配置し、
  8. Hyper-V 第二世代(vhdx)で仮想マシンを起動できる事を確認し、
  9. 書き換えた vhd を raw disk image に qemu-img で変換し、
  10. qemu で vhd と raw disk image の両方で仮想マシンが起動できる事を確認し、
  11. 仮想 Ubuntu の dd で、raw disk image を物理 SSD に書き込んで(512 bytes 書き込めず)、
  12. 物理 SSD から Hyper-V 仮想マシン (Path through接続) と実 PC (SATA接続) で起動できる事

以上の事が可能だった。

予想外だったのは次の3点:

  1. Debian installer が grub の中で /dev/sda 形式で root fs を指定していた。実 PC は複数の SATA device を接続しているので、認識順により、物理 SSD が sdb になっていた。update-grub で UUID 指定に戻った。
  2. Hyper-V 第二世代の Microsoft UEFI は、特定の場所に efi ファイルを入れておかないと起動出来ない。
  3. raw disk image を vhd に変換すると sector 数が増加してしまうので、raw disk image に再度変換すると元の image と大きさが変わってしまう。

現実には、アクセス速度に不満があって仮想ディスクから物理ディスクに置き換える場合には容量の大きめの SSD 等を準備するだろうし、仮に同容量の物理ディスクがあったとしても事前に gparted 等で partition の大きさを調整しておけば良いので、問題になる事は無いと思う。