元々は、build してみたい software があったので、余っていた 128GB SSD に linux を install してみよう、と考えたのが最初のきっかけだった。
- build は random access 多めだし Virtual disk のオーバーヘッドが加わるのは嫌だなぁ
- じゃあ素直に install して dual boot ? ちょっとつまらない
- DVD や CD の物理メディアを今更作るのは嫌だなぁ
- Hyper-V に Path through で物理ディスクを接続できる模様
- これだと、DVD image と Path through 物理 SSD で linux install できそう、やってみよう。
- 物理 <-> 仮想ディスク、実 PC <-> 仮想マシンでやり取りできたら面白そう。
という流れで、今回の作業を実施してみた。
これまで進めてきた内容をまとめると以下:
Desktop PC へ遊休 SSD 追加
Note PC で使用していた MLC 128 GB 品。古いし使い込んでいるし、S.M.A.R.T. で総書込量は見えないし、いつ壊れるか分からないが、放っておくのももったいないので Desktop PC に接続した。
Desktop PC 128GB SSD へ Ubuntu install (Hyper-V Pass through disk) その1
Desktop PC 128GB SSD へ Ubuntu install (Hyper-V Pass through disk) その2
Desktop PC 128GB SSD へ Ubuntu install (Hyper-V Pass through disk) その3
Path through 物理 SSD に Ubuntu18.04 を install し、Hyper-V 第一世代と実PC から起動出来る事を確かめた。Hyper-V 第二世代だと UEFI 環境になるので、実PC が BIOS だと仮想マシンと物理PC の両方で起動させる事は難しいと考えて、こちらは試していない。UEFI 環境でも MBR で起動できそうな記事が散見されるが、この先は順次 UEFI 環境への置き換えが進むし、MBR -> GPT の移行も可能なので、そこまでは必要ないと考えて試していない。
Desktop PC 128GB SSD へ Ubuntu install (Hyper-V Pass through disk) その4
linux が起動出来ない原因 (推測)
linux が起動出来ない原因 (判明)
Windows Subsystem for Linux から仮想マシン Ubuntu へ ssh 接続
linux の起動時に UUID で root filesystem を指定する方法
Ubuntu18.04 は desktop 環境としては便利だが、install と再起動を繰り返す時に時間がかかっていた。server で入れれば良いのかもしれないが、勝手が分かっている方が都合が良いので、Debian9.6 に distribution を変更し、X Window 等を入れずに最小構成で install した。
結果的に、distribution を変更した事が作業量が増える原因となった。予想外の事項その1。Debian9.6 だと grub.cfg に UUID を設定していなかった為に、実PC で起動できなかった。update-grub で直るので、installer 側の問題だと思う。起動直後の grub の画面からも root fs を指定できるので、一旦起動させてしまえばなんとかなる。
text base の log を取りたくなったので、WSL Ubuntu から ssh で仮想マシンに入られるようにした。Windows10 Ver.1809 から PowerShell でも ssh を標準で使えるが、WSL を使える環境で PowerShell 常用は難しかった。
Ubuntu18.04 cifs mount と物理SSD の仮想ディスク化
Ubuntu18.04 cifs mount と物理SSD の仮想ディスク化 その2
disk image scp 再度挑戦
結局は Windows10 Hyper-V の仮想マシンで、取り出した disk image を試すので、cifs(samba) で mount したフォルダに直接 dd で書き込んだ所、I/O error が発生して失敗した。予想外の事項その2。単純に cp しても同じ error が発生するので、linux の client 側か Windows10 の server 側か、あるいは設定の問題なのか判断できない。Windows10 だったらオオゴトになっていると思うので、多分 client か設定の問題だろうと予測している。
代わりに scp を使うと md5sum で check しても問題なし。pipe で dd -> scp へ直接渡す方法も見つけたが、今回は試さなかった。HDD 容量が厳しい条件の時に使ってみる。
仮想 Ubuntu 内の仮想マシンで disk image 動作確認
Desktop PC 128GB SSD へ Debian install (Hyper-V Pass through disk) その5
Desktop PC 128GB SSD へ Debian install (Hyper-V Pass through disk) その6
raw disk image -> vhd に変換するのに、vboxmanage を使うと失敗し、qemu-img を使うと成功した。あまり vboxmanage の使用例が見つからないと思っていたが、この部分に関しては qemu の方が確実なのかもしれない。
変換は全て仮想 Ubuntu 側で実施した。Windows側で行わなかったのに意味はないが、より安定しているであろう環境で変換したいという想いがあったのは否めない。
変換した vhd を 仮想 Ubuntu の中の qemu 仮想マシンで起動させ、問題なく起動する事も確認した。この先、x86(64) 以外に raspberry pi 仮想マシンも起動させてみたいと考えているので、良い経験になった。
Windows10 に移した vhd を使用して、Hyper-V 第一世代仮想マシンでは問題なく起動できた。Hyper-V 第二世代で起動させるのには少々時間がかかった。予想外の事項その3。MBR -> GPT の変換はすんなり終わったものの、Hyper-V Microsoft UEFI の画面から先に進めない。結局は、grub の efi ファイルを規定の位置に置かないとダメ、という結果だった。それが分かったので、vhdx への変換から順を追って再確認して、その後は問題なく起動できた。
Desktop PC 128GB SSD へ Debian install (Hyper-V Pass through disk) その7 (完)
vhd を Windows10 から 仮想 Ubuntu に移し、vhd -> raw disk image に変換、dd で Path through 接続した物理 SSD に書き込んだ。raw disk image -> vhd に変換した時に、sector が増加する事が分かった。幸い最終 partition は linux swap だったので、Hyper-V 第一世代も実 PCも、Path through 接続した物理 SSD から無事に起動する事が出来た。
1月14日から始めた作業も、ここまでで一区切りがついた。もう少し確認したい事が残っているが、これからも能力低めの PC で色々試せたらと思っている。
