このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

FreeBSD 12.1のvirtioドライバはバグってるっぽい?

FreeBSD 12.1-RELEASEのvirtioドライバは何かしら不具合があるようだ。仮想環境のゲストとして動かした際に、virtio経由のデバイスが認識されなかったり正しく動かなかったりする模様。もしかすると、12.0-RELEASEや11.3でも同様かも。

このところProxmox VEにお熱で、自宅のFreeBSDサーバをP2Vすべく調査や実験を行っている。P2Vと言ってもPCIパススルーやRaw Device Mappingなどを使い、本来の仮想化とは少々毛色が違うのだが、この構成にしとけばいつでもV2P出来るというメリットがある。

そんなわけで、起動ディスクのNVMe SSDをPCIパススルーし、VMを起動して無事FreeBSDの起動シーケンスが流れてktkrと思ってたら、忌まわしき「Mounting from zfs:zroot/ROOT failed with error 5.」で止まってしまった。

ZFSでこのエラーになってしまったら、ここから復旧できる見込みはまずない。

仕方ないのでProxmoxやVMの設定、KVMのパススルーまわりのあれこれの見直し、FreeBSD側の/boot/loader.confのチェックにzpool.cacheの再生成など、知る限りのあらゆることを試しても症状は変わらず。

起動メッセージをよーく確認すると「ptnetmap-memdev0: cannot map I/O space」「device_attach: ptnetmap-memdev0 attach returned 6」がチラホラ出ていた。

それらしい単語でググるとVirtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTSがヒットした。試したVMは確かにQ35で作ってるし、自分と同じくルートプールが見つからなくて起動できない報告もあるし、このバグを踏んだか?

スレを読んでも修正されたんだかされてないんだか分らなかったが、ふと、先行実験でパススルーしたNVMe SSDにインストールした12.2-RELEASEは問題なく起動してたのを思い出した。それならばってことで、いったん通常環境でFreeBSDを起動し、12.2-RELEASEに更新。その後、改めてVMの方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)

参考サイト

Proxmox VE 6.2とX10DRiとR7 430でGPUパススルーできた

念願のGPUパススルーができたので、記録として書き止め。環境は以下のとおり。

  • Proxmox VE 6.2-4
  • X10DRi
  • Xeon E5-2648Lv3 (VMに4コア割り当て)
  • Radeon R7 430
  • Windows 10 (20H2/x64)

ググれば出てくる方法で、何の苦労もなくできた。記念にDQXベンチVer.1.51の結果をペタり。

最高品質、1920×1080の設定でスコア7256のとても快適の評価となった。Twitterから同スコアを拾ってくると4700、7800、8000、8600、9400って感じでバラついてて何とも言えない所ではあるが、GPUパススルーのオーバーヘッドはそれほど大きくはなさそう。

ついでにリモートデスクトップ経由でベンチした結果はこちら。

これでメインマシンをサーバに収容する計画が一歩前進だなー。実現した場合、Ryzen 3.0GHzおじさんからHaswell-EP 1.8GHzおじさんへと大幅退化することになるわけだが…。H11SSL-iとEPYCほすぃ……。

ブリッジネットワーク接続の仮想マシンを使う時はport-securityに気をつける

ブリッジネットワーク接続の仮想マシンがあり、その通信がCiscoのCatalystスイッチを通るネットワーク構成の時は、スイッチのポートセキュリティ設定に気をつけなければならない。さもないと仮想マシンが通信できなくてハマる。VMとLAN内の物理マシンとでARP RequestとReplayは通っており、互いのARPテーブルは正しく作られているように見えるのに通信が出来なくて超ハマる。3ヶ月くらい悩んでた…(ヽ´ω`)

port-securityが有効なポートでは、最初に通過したMACアドレス以外のフレームが破棄される。

ここで、ブリッジ接続の仮想マシンのフレームは、物理マシンが繋がってるポートに流れる事になる。つまり、1ポートに対して複数のMACアドレスが関連付けられるわけだが、port-securityが有効だと最初の通信のMACアドレスしか有効にならない。それは殆どのケースで物理マシンのMACアドレスになるので、VMは一切通信出来なくなるという寸法。逆にいえば、物理マシンの通信ならOKなので、NATでVMの通信を物理マシンの通信に変換してやれば通信できるということだ。実際、NAT接続でなら通信出来てた。

対策方法は次の3つ。

  1. port-securityを無効化する
  2. 信頼するMACアドレスを静的に追加する
  3. 学習するMACエントリの上限を引き上げる(デフォルトでは1個)

自宅ネットワークならport-security無効化が簡単で影響も殆どないかと。

この問題を調べてる時に、ブリッジ接続が上手くいかないと嘆いているロシアのフォーラムを見つけたんだけど、結局使ってるホスティング業者を変えたら動いた!って結末だったので、恐らくダメだった方の業者のスイッチで似たようなセキュリティ設定になってたんだろうと思う。

原因がわかって全てが繋がった感じ。通信だけにね(´・∀・` )

参考サイト

VirtualBox上のWin 7でディスクイメージとzvolの速度比較(ついでにbhyveも)

仮想マシンのストレージ形式について、一般的にはイメージファイルよりもzvolの方が適していると言われている。ホストのファイルシステムレイヤを通過したファイル上にゲストのFSレイヤを通したFSを構築するよりかは、zvol(の薄いレイヤしか通らない)のブロックデバイスをゲストのFSレイヤに渡した方が効率が良さそう、ってのは理屈としても合っている。

以前から実際に速度比較しようと思いつつ、ようやく実行に移せた。環境は以下の通り。

  • ホスト
    • FreeBSD 11.1-RELEASE-p1
    • VirtualBox 5.2.0
      • CPU: Xeon E5-2648Lv3 1.8GHz 12C24T
      • RAM: 64GB
      • SSD: Intel DC S3500 480GB
        • SATA 3接続
        • ZFSのLZ4で透過圧縮している
  • ゲスト
    • Windows 7 Ultimate (x64)
      • CPU: 4コア
      • RAM: 8GB
      • SSD: VirtIO 40GB

ゲストのストレージを、同一内容のイメージファイルとzvolデバイスとで切り替えてCrystalDiskMark 6.0.0で速度を計測した。なお、イメージファイルからzvolへの変換は以下のコマンドで行った。

VBoxManage clonehd /path/to/vms/Windows/HDD.vmdk /path/to/vms/HDD.raw --format RAW
zfs create -V 40G zvm/zvols/Windows
dd if=/path/to/vms/Windows/HDD.raw of=/dev/zvol/zvols/Windows bs=4096
VBoxManage internalcommands createrawvmdk -filename /path/to/vms/Windows/zvol.vmdk -rawdisk /dev/zvol/zvols/Windows

<align center></align>

おろ、殆ど変わらんがな…(´・ω・`)。シーケンシャルR/W共にSATA 3の上限ぶっちぎっちゃってるし、ホストのキャッシュが効いちゃってる?

というわけで、VirtualBoxの「ホストのI/Oキャッシュを使う」オプションを切って再計測。

<align center></align>

すごく、、、速いです………。こりゃZFSのキャッシュが効いてるなー。確認してみるとARCで4.8GB持ってるしなー。ベンチ中にtopで見てるとARCがもりもり増えてくし。

ついでにイメージファイルをHDDに置いた時のベンチも取ってみた。

うっは2.5インチHDDとは思えぬ速さwwwww

zpool iostatの結果を見るに、ランダムライトはZFS側でまとめられ、ほぼシーケンシャルライトとしてHDDに書き出されているようだ。

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      1    922   153K   105M
  mirror    1.33T  1.38T      1    922   153K   105M
    ada3p1      -      -      0    861  25.5K   105M
    ada2p1      -      -      0    875   127K   107M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      2    932   277K   111M
  mirror    1.33T  1.38T      2    932   277K   111M
    ada3p1      -      -      0    919  50.4K   114M
    ada2p1      -      -      1    890   227K   110M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.33T  1.38T      0    962   102K   119M
  mirror    1.33T  1.38T      0    962   102K   119M
    ada3p1      -      -      0    941   102K   117M
    ada2p1      -      -      0    965      0   120M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zhome2      1.34T  1.38T      1    940   153K   113M
  mirror    1.34T  1.38T      1    940   153K   113M
    ada3p1      -      -      0    918  76.7K   113M
    ada2p1      -      -      0    906  76.7K   112M
logs            -      -      -      -      -      -
  mirror      40K  3.97G      0      0      0      0
    ada0p4      -      -      0      0      0      0
    ada1p4      -      -      0      0      0      0
----------  -----  -----  -----  -----  -----  -----

結論としては、イメージファイルでもzvolでも大差なさそう。ストレージ形式の差よりも、ZFSそのものの動作環境やチューニングの差の方が覿面に影響しそう。なので、好きな方を使えばいいんじゃないかな。俺は扱いやすいイメージファイルの方を選ぶんだぜ。

とりあえずZFSパネェ…。


(2017-11-25 追記)

ついでにbhyveでもやってみた。

ストレージは同一SSDだけど、計測環境は新規インストールのWindows 10なので厳密な比較にはならんけど。なお、ストレージはahci-hdで繋いでる。virtio-blkはWindowsでは現状未対応らしい。

ベンチ結果は左から、gzip-5のZFS上のイメージファイル、同zvol、lz4なzvol。

<align center> </align>

家鯖をESXi 5.1U2からV2P, V2Vマイグレーション

家鯖をESXiによる仮想サーバから物理サーバにマイグレーションする事にした。

ESXi上で動いているのはFreeBSDとWindows 7の2つ。元々FreeBSDが物理的に動いていたが、Windowsで録画鯖を作ろうと思ってESXiを導入したという経緯がある。結局、nasneを買っちゃったし、そもそも元からテレビを見ないという致命的な不具合(笑)が発覚したので、録画鯖を仕立てる理由もなくなってしまった。ESXiの雲行きも怪しいし、良い機会なのでV2Pしちゃおうと考えた次第。

FreeBSDは物理サーバ時代からのHDDを全てRDM&PCIパススルーで動かしてた為、マイグレーションもへったくれもない。ESXiのUSBメモリを引っこ抜けば、何もしなくてもBSDが起動する素敵仕様。V2Pいっちょあがりっと。

Windowsの方はFreeBSD上のVirtualBoxにV2Vする事にした。録画鯖にはならなかったものの、PS Vitaのコンテンツ管理アシスタントのホストになってたり、巨大なエロ動画ファイルのダウンロードとかで地味に役立つので。こっちは少し苦労したため、作業内容をメモっておく。

ESXiのWindows 7をVirtualBoxにマイグレーション

ファイルのコピー

まずはESXiのデータストアからファイルを取り出さない事には始まらない。色々やり方はあると思うが、今回はクライアント側からscpで転送した。

$ scp -rp root@esxiserver:/vmfs/volumes/path_to_datastore/Windows/ esxi_save/
Password: 
Windows.vmx                                   100% 3142     3.1KB/s   00:00    
Windows.vmxf                                  100%  262     0.3KB/s   00:00    
Windows.vmsd                                  100%    0     0.0KB/s   00:00    
Windows.nvram                                 100% 8684     8.5KB/s   00:00    
vmware-36.log                                 100%  202KB 202.1KB/s   00:00    
Windows-flat.vmdk                             100%   40GB  42.9MB/s   15:55    
Windows.vmdk                                  100%  494     0.5KB/s   00:00    
vmware-35.log                                 100%  202KB 201.6KB/s   00:00    
vmware.log                                    100%  311KB 311.1KB/s   00:00    
vmware-31.log                                 100%  176KB 175.8KB/s   00:00    
vmware-32.log                                 100%   51KB  51.4KB/s   00:00    
vmware-34.log                                 100%  202KB 201.9KB/s   00:00    
vmware-33.log                                 100%  180KB 180.2KB/s   00:00

VirtualBoxに仮想マシンを作成

VMの詳細は割愛。

ストレージは既存の仮想ディスクを使う。上で転送したファイルで言えばWindows.vmdkを選択する。

接続するバスは、とりあえずESXiで使っていた物と同じのにして、Windowsが起動するか試してみる。正常に起動すれば後は何もする必要はないが、十中八九「Windowsを起動しています」の画面で“STOP 0x0000007B”ブルースクリーンが出て死ぬ。その時は、接続バスを好きなものに変えて(もちろん変えなくてもいい)、次の対策を行う。

“STOP 0x0000007B”対策

“STOP 0x0000007B”ブルースクリーンが出てWindowsを起動出来ない時は、レジストリを修正する必要がある。

  1. VM起動時にF8連打でWindowsの「詳細ブートオプション」を表示し、「コンピュータの修復」を選ぶ。コンピュータの修復が表示されていなければ、修復用のシステムがインストールされていないって事なので、WindowsのインストールCDから同等の事をする(詳細はググってくだしあ)。
  2. システム回復オプションのログイン画面が出るので、正常に動いてた時のアカウントでログイン。
  3. コマンドプロンプトを起動。
  4. コマンドプロンプトで「regedit」と打ち、レジストリエディタを起動。
  5. レジストリエディタの「HKEY_LOCAL_MACHINE」または「HKEY_USERS」を選択した状態[ファイル]>[ハイブの読み込み]を選択。
  6. d:\Windows\System32\config\SYSTEM を開く。
  7. マウントポイント名を聞かれるので、適当にattachedなどと入れる。
  8. attachedにSYSTEMレジストリが読み込まれるので、CurrentControlSet\servicesControlSetNNN\servicesの中にある下記リスト内の「Start」の値を0にする。ノードが存在しなければ飛ばしてOK。
    • aliide
    • amdide
    • atapi
    • ataport
    • cmdide
    • intelide
    • LSI_SAS
    • LSI_SAS2
    • LSI_SCSI
    • megasas
    • MegaSR
    • msahci
    • pciide
    • pciidex
    • viaide
  9. レジストリエディタ、コマンドプロンプトを終了し、再起動。

以上でマイグレーションしたWindowsが正しく起動するハズ。

参考サイト

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0