Docker Desktop for Windowsを導入してみました。

dockerコンテナを作って動かしたいのが目的です。 Windowsを使うのは、普段使っているOSがWindowsだからで、コンテナはLinuxのものを使います。 そうしたときに、docker Engineをどこで動かすかの選択肢があります。

• Windows （Docker Desktop for Windows）
• Windows上のLinux VM（Hyper-VやVirtual Box上のLinux VMでLinux用のDocker Engineを動かす）

開発用にLinux VMを動かしているのでそちらでDockerを使っても良いのですが、わざわざVMを起動して使うのも面倒そうなのでWindows上で動かすことにしました。 ただ、Windows上で動かすと言っても、実際にはDocker用のLinux VMがHyper-Vを使って起動します。 そのため、自分でLinux VMを用意して動かすのと仕組みはそれほど変わりません。

Docker Desktop for Windowsの場合、Docker ClientはWindows上で動きますが、Docker EngineはLinux VM上で動きます。 自分でLinux VMを用意して使う場合はDocker ClientもDocker EngineもLinux VM上で動きます。 コンテナそのものはどちらもLinux VM上で動きます。

Docker Desktop for Windowsを使う場合、DockerfileやコンテナにコピーするファイルをLinux VMから利用できるようにする必要があります。 どのドライブをアクセス可能にするかは、settingsから設定できます。 なお、コンテナからマウントして使うようなデータ領域としてはWindows上の領域は不向きで、data volumeやdata containerを使う方が良いようです。これには二つの理由があって、一つはWindows上の領域はLinux上からみて、rwxrwxrwxのモードで見えます。もう一つは、SMBを使ってLinux VMに領域を見せる際、NOBRLオプションが付いているため、ロックができない場合がある点です。 これらはDocker Desktop for Windowsのドキュメントの最初の方（Shared drives）に書いてあります。

と、ここまでやってから大事なことに気づきました。 開発用にLinux VMを動かしていますが、そちらはVirtual Boxを使っています。 Docker Desktop for WindowsはHyper-Vを使います。 これらの共存はできないので、どちらを使うか選ぶ必要があります。。つづく。。

というわけで、前回の続きです。

前回、原因究明はできたけれどもその報告ができていませんでした。 一日以上経って、ようやくForumにポストできました。

Can the failure message be improved? When VBoxManage.exe import failed with no disk space.

そして、Forum Postig Guideのデッドリンクについてもポストしておきました。

Dead link found in The Forum Posting Guide

誰か反応してくれると良いなぁ。。

vagrant upがなぜか失敗するのでその原因究明をしたときの話です。

事象

PS E:\vagrant> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'hashicorp/precise64' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'hashicorp/precise64'
    default: URL: https://vagrantcloud.com/hashicorp/precise64
==> default: Adding box 'hashicorp/precise64' (v1.1.0) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/hashicorp/boxes/precise64/versions/1.1.0/providers/virtualbox.box
    default: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    default:
==> default: Successfully added box 'hashicorp/precise64' (v1.1.0) for 'virtualbox'!
==> default: Importing base box 'hashicorp/precise64'...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["import", "\\\\?\\E:\\vagrant_home\\.vagrant.d\\boxes\\hashicorp-VAGRANTSLASH-precise64\\1.1.0\\virtualbox\\box.ovf", "--vsys", "0", "--vmname", "precise64_1571241203898_82313", "--vsys", "0", "--unit", "12", "--disk", "D:/VMimages/precise64_1571241203898_82313/box-disk1.vmdk"]

Stderr: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interpreting \\?\E:\vagrant_home\.vagrant.d\boxes\hashicorp-VAGRANTSLASH-precise64\1.1.0\virtualbox\box.ovf...
OK.
0%...
Progress state: E_INVALIDARG
VBoxManage.exe: error: Appliance import failed
VBoxManage.exe: error: Code E_INVALIDARG (0x80070057) - One or more arguments are invalid (extended info not available)
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleImportAppliance(struct HandlerArg *)" at line 957 of file VBoxManageAppliance.cpp
PS E:\vagrant>

先に原因を書きますが、上記のように引数が悪いと言われますが、実際はディスクの空き容量が不足しているのが原因でした。

環境

Host: Windows 10 Guest: (何でも）

Vagrant: 2.2.5、2.2.6 Virtual Box: 6.0.12、6.0.14

原因究明

エラーメッセージでググってみると以下のissueに該当しているのを発見！

Invalid arguments to vboxmanage (potentially malformed path) #10832

ところが、未解決のままcloseしていました。 一日寝かしてみましたがやっぱり解決しないので新規オープンしようと思って 報告ルールに従って情報を集めていたらデバッグログの出し方があったのでこれを見てみました。 すると、VBoxManage.exeが失敗していたのだとわかりました。 VBoxManage.exeはvagrantではなく、Virtual Boxのコマンドです。

そこで、VBoxManage.exeの実行方法を調べて同じ引数で実行してみます。すると、再現します。

vagrantの呼び出し方が悪いのか、VBoxManage.exeが悪いかを切り分けます。 VBoxManage.exeの引数をいろいろと変えて試してみました。 すると、diskのファイル名（.vmdk）の指定を変えると成功する場合がありました。 指定の仕方によるのかも思いいくつかのパターンを試しましたが結論としては、ディスクの空き容量が足りていないと失敗することがわかりました。

つまり指定するドライブの問題です。ドライブを指定しているのは誰かというとVirtual Boxです。 Virtual Boxの「デフォルトの仮想マシンフォルダー」が使われています。 というわけで、この設定を変えることで解決できます。

問題の報告でも苦戦

Vagrantのissueに挙がっていたので同じ問題で悩む人もいるのだろうということで、関係各所に報告することにしました。 Virtual Boxのメッセージが分かりにくいのが良くないと思うのでメッセージの改善依頼を出してみることにしました。

Virtual BoxのForumがあるのでとりあえずそこで報告しようと思ってPosting Guidを見てみると、ユーザ登録が必要となっています。 registerのリンクをクリックするとNot Foundとなって登録できません。 loginのリンクは生きていたのでそちらを見てみるとOracleのログイン画面です。 アカウントを作成して無事にログインしてどう伝えるのが良いか考えてみましたが、モデレータへDMを送る機能があるようなのでそこに送ろうとしました。 しかし、URL入りのメッセージを送るにはユーザ作成後5日と5ポストの実績が必要だそうです。そんなにポストする予定はないので普通のTopicとしてポストすることにします。

Suggestionsという分類があるのでそちらでポストしようとしたら、今度はURL入りのポストはユーザ作成後1日と1ポストの実績が必要だそうです。 URL入りを送るのは難しそうなのでじゃあ、もうURL入れずに送ろうと思って送ろうと思ったら、ユーザ作成後1日経たないとURL無くてもポストできないそうです。 本題のメッセージの改善についても同じ理由でポストできませんでした。

もう疲れちゃいましたが、明日こそポストしてみます。

Windows 10のマシンがブルースクリーンになってしまって、再発すると困るので見てみました。 ググってみるとちょっと見てみるところまでは簡単にできそうだったのでやってみました。

結果はDPCウォッチドッグに引っかかっているみたい。（以下は、!analyze -vの抜粋）

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000000, A single DPC or ISR exceeded its time allotment. The offending
    component can usually be identified with a stack trace.
Arg2: 0000000000000501, The DPC time count (in ticks).
Arg3: 0000000000000500, The DPC time allotment (in ticks).
Arg4: fffff8003376e350, cast to nt!DPC_WATCHDOG_GLOBAL_TRIAGE_BLOCK, which contains
    additional information regarding this single DPC timeout

そしてkの結果には以下の文字列が。

rt640x64!MpHandleRecvIntPriVLanJumbo+0xb41
rt640x64!MPHandleMessageInterrupt

ここを見ると、スタックとレースのちょっと下で読んでる関数が問題なんだろうとわかるので、Realtekのドライバかなと思って、RT640x64でググってみるとやっぱりRealtekのドライバでした。最新のドライバにしてみたら？とコメントもあるし、そういえばMicrosoftから提供されているドライバしか入れてないなと思ったのでインストールしてみました。 これで安定してくれると良いなぁ。。

なお、ドライバインストールをそのNICを使ってリモートデスクトップでログインしながらやったので、途中で通信止まってしまいましたが少ししたらまたつながって一安心というのをしました。 さらに、PriVLANという文字列があったので、「優先度およびVLAN」という設定を無効にしたら、またしても一瞬通信が途絶えて、「あっ」ってなってしまいました。ちなみにジャンボフレームは無効になっていました。

ドライバの場所

https://www.realtek.com/ja/component/zoo/advanced-search/80?Itemid=389

デバッグ方法、他

日本語ページのリンクにしてますが、読みにくいので英語版で読む方が良いような気がします。。

メモリダンプに !analyze -v するまで・前編 ~ ダンプの取り方~ WinDbg を使用してクラッシュダンプファイルを分析する Stop エラーまたはブルー スクリーン エラーに対する高度なトラブルシューティング ドライバーの検証ツール ドライバー検証ツール !analyze !analyze 拡張機能の使用 バグ チェック 0x133 DPCウォッチドッグ違反

ダウンロード用シンボルのURL設定 SRVc:\websymbolshttp://msdl.microsoft.com/download/symbols

合わせて読みたい

キーボード操作でメモリ ダンプ ファイルを作成できる Windows の機能 DriverObject と DriverEntry ダンプファイルに保存された ETW トレースログを表示する ダンプファイルに保存されたイベントログを取り出す

mtdataapiに記事のダウンロード機能を設けました。

以下のコマンドでダウンロードできます。 ダウンロード先は、g:mt_basedir です。この配下にサイトIDのディレクトリが作られます。各エントリはエントリIDのファイル名になります。

let g:mt_basedir = $HOME/mtblog
:mtdataapi#downloadSiteToFile()

Movable Type 用 Vim Plugin: mtdataapi.vim