会社でUbuntu 20.04 Desktopを使いたくなったので、OSをインストールし、NATで固定IPアドレスな状態にする。
画面の表示はダイレクトに見えるものの他に、リモートデスクトップによる接続もできるようにする。
ディスクのパフォーマンスがやたらと悪かったりするので、そこにも手当てする。
とても簡単に使えると思ってはじめたのだが、思った以上に長くなってしまった。
環境
OSはWindows 10 Pro 21H2。
CPUはIntel Core i5-4590、メモリは32GB。
ディスクはSSDx1、HDDx1で、仮想環境はすべてHDDに入れる。
VMware Workstation Playerが稼働しており、過去に同居を試して失敗したため、Hyper-Vを止めて、Hyper-V関連のサービスをすべて無効にして、VMwareを安定化させた経緯がある。
Hyper-Vを使えるようにする
インストール
Windows の機能でHyper-Vにチェックを入れ、要求されたらWindowsを再起動する。
過去にHyper-Vのサービスをすべて無効にしていた。
そのため、ブルースクリーンさせながら試行錯誤して必要なサービスを起動し、以下の設定に落ち着いた。
素の状態にインストールしていったらどうなるのかと思い、別のPCで試してみたら、Hyper-V ゲスト コンピューティングサービス というのがなかった。
うちの環境では、このサービスを有効にするとブルースクリーンが発生するから、何かの拍子に入って、その後に不要になったけれども消える契機がなく、取り残されているということなのだろう。
仮想マシンの作成と運用
データー類の保管場所
ホストとなるPCのOSやアプリケーションはSSD、データー類はHDDに入れる運用をしているので、Hyper-Vが作成するすべてのデータ類(ディスクイメージを含む)をすべてHDDに入れたい。Hyper-Vを起動すると、最初に表示されるクイック作成はキャンセルして、デフォルトの保管場所を設定していく。
仮想ハードディスクにD:\Hyper-V\HDD、仮想マシンにD:\Hyper-V\VMを指定したところ、D:\Hyper-V配下にデーター類が保管されるようになるようだ。
クイック作成
仮想マシンのクイック作成に、Ubuntu 20.04があったので作成してみる。
セキュアブート無効、メモリ2GB、プロセッサ2個の仮想マシンができあがった。
設定よりも多くのメモリー(7GB)が割り当てられており、ディスク容量は12GB、カーネルは5.4.0となっていた。
$ uname -r 5.4.0-26-generic $ sudo fdisk -l /dev/sda Disk /dev/sda: 12 GiB, 12884901888 bytes, 25165824 sectors …
割り当てるメモリーの固定
クイック作成した仮想マシンは、メモリーは2GBと定義しているけれども、実際には7GBが割り当てられていた。
先日16GBメモリーのPCで2台目の仮想マシンを起動しようとしたところ、メモリー不足で起動ができない問題が発生した。4GBマシン2台が何故立ち上がらないのかと調べてみたら、勝手に割り当てるメモリーを増やしているのが原因だった。今回も5GB程多くのメモリーが割り当てられている。
設定項目を確認すると「動的メモリ」というのがあり、これが柔軟にメモリーを上下させる機能のようなんだけれども、稼働中の仮想マシンからメモリーを回収して、新たに起動しようとしているPCに割り当てる…的な動作はできないようだ。メモリー設計をちゃんとしても、最初に起動したホストが想定以上のメモリーを勝手にとってしまい、それを返してくれないデメリットしかなかった。
仮想マシンの動的メモリのチェックを外すことで、計画通りにメモリーを使うようになる。
VMwareとかだと、物理メモリー以上の仮想マシンを動かすこともできたりするよなー。全体のメモリー使用量が多すぎると遅くなっちゃったりするけれども、2→7GBを割り当てて返してくれないなんて動きはしないから、動的メモリーなんてのと比べてだいぶ管理しやすいように思う。これは、何のために付けた機能なのか不思議。
ディスクのパフォーマンス改善
ISOからのインストールに非常に時間が掛かり、その後、試しにLive CDを作ってみた時にもやたらと遅いと感じていた。
そこで、ディスクのパフォーマンスを調べてみた。
ask ubuntu / How to check hard disk performance
$ sudo hdparm -Tt /dev/sda $ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
| 仮想マシン | hdparm Timing cached reads | hdparm Timing buffered disk reads | dd if=/dev/zero | dd if=/dev/urandom |
|---|---|---|---|---|
| Hyper-V Quick | 10348.13 MB/sec | 142.97 MB/sec | 1.7 GB/s | 202 MB/s |
| Hyper-V ISO install + barrier=0 | 11958.15 MB/sec | 305.46 MB/sec | 1.2 GB/s | 191 MB/s |
| VMware Workstation Player 16 | 6832.52 MB/sec | 216.13 MB/sec | 382 MB/s | 196 MB/s |
Hyper-Vはこういうのには強いらしい。
でも、こうやってパフォーマンスチェックをしてみて、dd(/dev/zero)までを終えたところで、体感と違う…と思い、apt dist-upgradeを実行してみたところ、展開スピードがあからさまに遅い。VMware Playerと比較にならない遅さ。UbuntuをISOからインストールしたときの猛烈な遅さも、これが原因なのだろう。
あまりの猛烈な遅さに我慢できず、tty3からログインして強制的にシャットダウンさせたのだが、その後はこの仮想マシンが立ち上がらなくなった。
仕方がないので、仮想マシンを削除して再作成したのだが、今度はイメージのダウンロードがされず、あっという間に仮想マシンができた。
余談…
これはギャラリーと呼ぶらしい。どこかにイメージを保管しているんだと思うんだけれども、それがどこなのかはよく分からない。気が付いたらシステムドライブで物凄い容量を食っているタイプのこれ、本当に嫌だな。保管する場所も設定できると良いのだけれど。
さて、作り直した仮想マシンを起動し、今度は以下の変更を加えて再起動し、apt dist-upgradeしてみる。
このパラメーターは以前に調べていたもの。
銀の鍵 (The Silver Key) / ext3/ext4ファイルシステムのチューニング
/etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
LABEL=UEFI /boot/eft vfat defaults 0 0
LABEL=desktop-rootfs / ext4 defaults,barrier=0 0 0
この設定を入れると、体感できるほどに早い。
そこで、アップデートでどの程度の時間差が出るのか、同じホストにミラーサーバーを立てておき、更新完了までの時間を計ってみた。
$ date; sudo apt -y dist-upgrade; date
| barrier=0指定 | アップデートに掛かった時間 |
|---|---|
| あり | 00:11:14(12:56:11 → 13:07:25) |
| なし | 00:59:46(13:13:50 → 14:13:36) |
なんと5.3倍ほど速くなっている。実際、アップデート中のUnpackingのスピードが全然違うことが見た目ではっきり分かる程だった。
以上のことから、仮想マシンはマシンはクイック作成で作成し、ディスクをマウントする際にはbarrier=0を設定することが、普通に使えるマシンを素早く作る最適解になる模様。
安全性を犠牲にすることになるかもしれないが、この処理時間の差はあまりにひどすぎるから採用。
安全性とはいっても、そうそう簡単に壊れるわけでもないし、いざとなったら作り直せば良いと割り切れるなら、この程度でいいんだと思う。
仮想マシンの新規作成
ISOからのインストール
Ubuntu serverはクイック作成になかった。
凄く遅いけど、インストールできなくはないので、OS起動後に前述のディスクマウントオプションを変更すれば、その後は普通に使えるのではないだろうか。
寝る前にセットして寝て、朝起きたらできているとか、そんな時間的な余裕を持ってインストールしていけばいいのかなーと。
この手順もまとめてみようかと思ったけれど、既にきっちりとまとめてくれている方がいた。
Qiita / Windows 10 Pro Hyper-V に Ubuntu 18.04 LTS をインストール
こちらを一通り読めば、好きなOSをちゃんとインストールできるだろうと思われる。
UEFIとLegacy BIOS
一口に言えば、第1世代はLegacy BIOS、第2世代はUEFIになる。
作成後に変更することはできないので、どちらを使うのか決めておく必要がある。
変更できなくする必要があるのかどうか分からないが、少なくとも仮想ディスクのパーティション管理はMBRとGPTの違いがあるから、切り替えてもそのままでは起動しないことは確か。余計なトラブルを生まない知恵なのかもしれないが、Boot Repairで簡単に修復できちゃったりするような…まぁいいや。
クイック作成で作られるUbuntu 20.04は、第2世代でセキュアブートなし、であった。
UEFI+セキュアブート
UbuntuはMicrosoftに署名してもらったブートローダーを持っているはずなので、セキュアブートには対応しているはず。そして、その先は、Canonicalが署名したファイルを読み込んでいくトラストブートがちゃんとできている認識。
ということで、セキュアブートさせてみたところ、まったく問題なく起動する。
セキュアブートを有効にしたら、Microsoft UEFI 証明機関を選択すればOK。
起動後に、ターミナルから以下のコマンドを入力すれば、セキュアブートが有効になっていることを確認できる。
$ bootctl status
systemd-boot not installed in ESP.
system:
Firmware: n/a (n/a)
Secure Boot: enabled
Setup Mode: user
<omit>
なぜ、セキュアブートが有効になっていないのか…と考えてみたが、そもそもUbuntuを動かすなら、セキュアブートである必要はない。そして、何らかのドライバーをインストールしたときに、それが署名されていないと起動時に問題が発生するかもしれない。仮想マシンでWindowsとUbuntuのデュアルブート環境にしなければならない、というケースはとても少ないだろうから、余計な問題を起こさないようにしているのかなと思った。
ディスク容量の拡張
クイック作成で作られたディスクのサイズは12GBだった。もう少し広げたいと思ったら、ディスクの編集でサイズを広げ、パーティションを拡張すれば良さそうだった。
ただし、編集するにはチェックポイントをすべて解消しておく必要があるようだった。
結局、変更点をガシガシと保管しているらしく、整合性がとれなくなってしまうのだろうと思われる。
仮想ディスクのサイズは40GBになったので、仮想マシンを起動してサイズを確認してみる。
$ sudo fdisk -l /dev/sda
GPT PMBR size mismatch (25165823 != 83886079) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
Disk model: Virtual Disk
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: gpt
Disk identifier: FB54BF5A-F6A4-4AA7-86BE-6A0448B95C46
Device Start End Sectors Size Type
/dev/sda1 227328 25165790 24938463 11.9G Linux filesystem
/dev/sda14 2048 10239 8192 4M BIOS boot
/dev/sda15 10240 227327 217088 106M EFI System
40GBになっていて、sda14 → sda15 → sda1 の順でパーティションが並んでいることが分かる。
また、デバイスの最後にGPTテーブルのバックアップがない、と教えてくれている。
ディスクを単純に広げただけなので、その通り。
1をディスクの最後まで広げれば良さそうだ。
技術メモメモ / Ubuntu 20.04でシステム領域のディスク容量の拡張を行う
最初はGPTの修復、次にパーティションの拡張。
$ sudo parted /dev/sda GNU Parted 3.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 58720256 blocks) or continue with the current setting? Fix/Ignore? Fix Model: Msft Virtual Disk (scsi) Disk /dev/sda: 42.9GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 14 1049kB 5243kB 4194kB bios_grub 15 5243kB 116MB 111MB fat32 boot, esp 1 116MB 12.9GB 12.8GB ext4 (parted) resizepart 1 Warning: Partition /dev/sda1 is being used. Are you sure you want to continue? Yes/No? Yes End? [12.9GB]? 100% (parted) quit Information: You may need to update /etc/fstab.
必要か分からないが、念のため。
$ sudo partprobe /dev/sda
最後のメッセージが気になったので、パーティションのラベルを確認してみる
$ ll /dev/disk/by-label/ total 0 drwxr-xr-x 2 root root 80 2月 13 15:55 ./ drwxr-xr-x 7 root root 140 2月 13 15:55 ../ lrwxrwxrwx 1 root root 10 2月 13 16:19 desktop-rootfs -> ../../sda1 lrwxrwxrwx 1 root root 11 2月 13 16:19 UEFI -> ../../sda15 $ cat /etc/fstab # UNCONFIGURED FSTAB FOR BASE SYSTEM LABEL=UEFI /boot/efi vfat defaults 0 0 LABEL=desktop-rootfs / ext4 defaults,barrier=0 0 0
問題なし。
パーティションだけ拡張しても容量が増えない…ファイルシステムの拡張が必要。
$ sudo resize2fs /dev/sda1
容量が拡張できた。
表示倍率のリセット方法
ちょっと画面を小さく表示させたいと思って、25％を選択したところ、表示(V)というメニューにどうやってもたどり着けず、すべての端末が25%で表示されるようになった。
そんな馬鹿な！とお思いでしょうが、ALTでメニュー選択をしようとしても、表示されている「ファイル」「操作」「メディア」をグルグルと回るだけで、元々表示されていた他のメニューは表示されないのです。いやー、これを見て、Hyper-Vってホントに駄目だなーって思って画面の前で声を出して笑ってしまった(ディスクの遅さを感じた後だったのもあるけど)。
修正方法はここにあった。
Microsoft Community / How to restore auto zoom level in Hyper-V VM window
すべてのセッションを閉じる(Hyper-V マネージャーや仮想マシンは起動したままで大丈夫)。
その後に、テキストエディタで以下のファイルを開いて、25となっていたのをautoに修正して保存。
%UserProfile%\AppData\Roaming\Microsoft\Windows\Hyper-V\Client\1.0\vmconnect.config
<omit>
<setting name="ZoomLevel" type="System.UInt32">
<value>auto</value>
</setting>
<omit>
表示が元に戻る。
仮想マシンの運用
拡張セッション
仮想マシンとディレクトリを共有したい、全画面表示をさせたい、といった話は、これで解決するのが簡単な模様。
実際にインストールしてみると、xrdpにリモート接続している感じだった。
これを簡単に動くようにしてくれるプロジェクトはこちらで、Microsoftがやっていたみたい。
16.04と18.04が入った状態でアーカイブされていて、WSL2推奨ということになっちゃったようだった。
Github / Microsoft / linux-vm-tools
20.04で動作するのどうか…と思ったらこちらで実際に動かしていて、わかりやすく手順を教えてくれていた。
SEECK.JP サポート / Hyper-V Linux で拡張セッションを使う方法
NAKIVO / Detailed Walkthrough: Install Ubuntu 20.04 on Hyper-V with Enhanced Session
以降、ほぼまるごとこちらで教えてくれている手順からの引用。
拡張セッションを動かすために、Hyper-Vの設定で、拡張セッションモードを有効にする。
Hyper-Vサーバーの設定と、利用するユーザーの設定があったので、両方有効にしている。
スクリプトを使って、xrdpをインストールする。
起動するパーツなんかも指定してくれているので、素でインストールするより楽なんだろうと思われる。
$ mkdir ~/work $ cd ~/work $ wget https://raw.githubusercontent.com/Hinara/linux-vm-tools/ubuntu20-04/ubuntu/20.04/install.sh $ chmod +x install.sh $ sudo ./install.sh
ぱっと見は、これでxrdpの環境が作られるのかな、という感じ。
上では有志のinstall.shをダウンロードしてきて利用しているので大丈夫だけれども、Microsoftの最終版をダウンロードしてきて使った場合には、以下の修正が必要。
いろいろ備忘録日記 / Ubuntu 21.04で拡張セッションを有効にして全画面で接続する (Hyper-V)
/etc/xrdp/xrdp.ini
<omit> ;port=3389 port=vsock://-1:3389 <omit> ;use_vsock=false use_vsock=true <omit>
設定変更したら、xrdpを再起動。
$ sudo systemctl restart xrdp
続いて、ホスト側でPowerShell(x86)を管理者権限で開いてコマンドを実行。こちらも
SEECK.JP サポート / Hyper-V Linux で拡張セッションを使う方法
からの、まるごと引用。
> Set-VM -VMName "Ubuntu 20.04" -EnhancedSessionTransportType HvSocket
※黄色の部分は、自分のホスト名を書く。
これで、仮想マシンに接続するたびに「リモートデスクトップ接続」っぽい画面が表示されるようになり、好きなサイズで画面表示ができ、フォルダの共有なんかもできるようになる。
ただし、うちの環境では、以前にVMwareのライブラリをインストールしていたため、Set-VMを単純に実行すると、こんなエラーが出た。
これは、コマンドの名前が同じことが原因で、VMwareのコマンドが呼び出され、Hyper-Vの仮想マシンを操作できない状態になっていた。
> Set-VM -VMName "Ubuntu 20.04" -EnhancedSessionTransportType HvSocket Set-VM : パラメーター名 'VMName' に一致するパラメーターが見つかりません。 発生場所 行:1 文字:8 + Set-VM -VMName "Ubuntu 20.04" -EnhancedSessionTransportType HvSocket + ~~~~~~~ + CategoryInfo : InvalidArgument: (:) [Set-VM]、ParameterBindingException + FullyQualifiedErrorId : NamedParameterNotFound,VMware.VimAutomation.ViCore.Cmdlets.Commands.SetVM
この場合には、完全修飾名で呼び出せば動作した。
> Hyper-V\Set-VM -VMName "Ubuntu 20.04" -EnhancedSessionTransportType HvSocket
これらの設定結果は、以下で確認できる。
> Hyper-V\Get-VM -VMName "Ubuntu 20.04" | Select EnhancedSessionTransportType
EnhancedSessionTransportType
----------------------------
HvSocket
リモートデスクトップ接続
拡張セッションで発生したトラブルの回避策はこちら。
色々やってみたけれど、メインPCで拡張セッションが有効になることはなかった。設定を何度も確認したけど駄目。
仕方がない、xrdpをインストールしているのだから、そこに接続しよう。
/etc/xrdp/xrdp.ini
<omit>
port=vsock://-1:3389 tcp://:3389
<omit>
use_vsock=true
<omit>
※3389ポートの接続を追記。
設定変更したら、xrdpを再起動。ついでに、ポートの状態を確認してみると、3389は開いてない。
さらに、現在割り当てられているIPアドレスも確認。
$ sudo systemctl restart xrdp
$ sudo ss -p -A tcp,udp,raw state listening state unconnected -n
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
icmp6 UNCONN 0 0 *:58 *:* users:(("NetworkManager",pid=497,fd=21))
udp UNCONN 0 0 0.0.0.0:5353 0.0.0.0:* users:(("avahi-daemon",pid=493,fd=12))
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=453,fd=12))
udp UNCONN 0 0 0.0.0.0:41048 0.0.0.0:* users:(("avahi-daemon",pid=493,fd=14))
udp UNCONN 0 0 0.0.0.0:631 0.0.0.0:* users:(("cups-browsed",pid=585,fd=7))
udp UNCONN 0 0 [::]:5353 [::]:* users:(("avahi-daemon",pid=493,fd=13))
udp UNCONN 0 0 [::]:53162 [::]:* users:(("avahi-daemon",pid=493,fd=15))
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=453,fd=13))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=650,fd=3))
tcp LISTEN 0 5 127.0.0.1:631 0.0.0.0:* users:(("cupsd",pid=495,fd=7))
tcp LISTEN 0 2 0.0.0.0:3389 0.0.0.0:* users:(("xrdp",pid=655,fd=12))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=650,fd=4))
tcp LISTEN 0 2 [::1]:3350 [::]:* users:(("xrdp-sesman",pid=639,fd=7))
tcp LISTEN 0 5 [::1]:631 [::]:* users:(("cupsd",pid=495,fd=6))
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:15:5d:07:6c:08 brd ff:ff:ff:ff:ff:ff
inet 172.20.32.253/20 brd 172.20.47.255 scope global dynamic noprefixroute eth0
valid_lft 86214sec preferred_lft 86214sec
inet6 fe80::58a:90ef:4c2f:3996/64 scope link noprefixroute
valid_lft forever preferred_lft forever
次に、このターミナルでログアウトしている。
これが重要で、今の設定では、誰かがログインしているとセッションをつかんでしまう模様。
ログアウト後、リモートデスクトップ接続で接続する。
オプションのローカル リソースで、プリンターのチェックを外し、クリップボードにチェックを付ける。また、詳細設定でドライブだけを共有して、接続すると…xrdpのログイン画面が出てくるので、ユーザーとパスワードを入力して接続する。
クリップボードとドライブの共有ができた。音が鳴らないけど…今回はパス。
接続後に見ると、3389ポートもLISTENになっていて、どうやっているんだろうとは思うけれど、上手く接続ができる。
これで、動作確認やちょっとした業務であれば十分に使える環境になっていそうだ。
IPアドレスの固定
拡張セッションは良いのだけれど、ssh接続やリモートデスクトップ接続しようとしたとき、IPアドレスが固定されている方が都合がいい。
あるいは、名前解決できる形になっていれば扱いやすい。
ネットワークの構成方法は、こちらで詳しく図入りで解説してくれている。
Qiita / Hyper-Vのネットワーク設定についての覚え書き
Bridge
ウチの中にDHCPとDynamicDNSの仕組みを入れているので、ブリッジ接続にするだけで名前解決ができるようになっている。
DHCPがあってMACアドレスで固定のIPアドレスを振り出せるなら、実質固定IPアドレス扱いできる(と思われる)。
接続の種類を外部ネットワークとして、利用したいカードを選択(Wi-FiならWi-Fiのアダプタを選択)。
管理オペレーティングシステムにこのネットワークアダプターの共有を許可する、にチェックを入れる。
後は、仮想マシンでこのスイッチにに接続すればOK。
ただし、この接続はVMwareのブリッジ接続とのやりとりができなかった。ルーティングでどうにかできるとも思えなかった(技量的にもそうだし、ルーティングできる理屈がイマイチ思いつかない)ので、その接続は諦めた。
また、インストールしてから数ヶ月経ったある日、ホストとなっているPCがIPv6で通信できなくなった。
DHCPから払い出されたIPアドレスを、このブリッジがつかんで離さないのだ。結果としてホストはIPv6アドレスなしとなった。
IPv6なしでもいけるネットワークなら、ブリッジのIPv6を無効化し、IPv4アドレスも手で固定のものを振ると良さそうだ。
2022/04/09追記。
NAT
PCの下にNATでぶら下げる場合には、以下の設定をする。
塵積ぶろぐ / Hyper-V on Windows10環境で任意の固定IPアドレスを割り当てる方法
Microsoft Docs / New-NetNat
Microsoft Docs / NAT ネットワークの設定
ここでは、NATルーターとして192.168.55.1を設定してみた。
そして、PowerShellを管理者で開き、仮想スイッチのNAT設定を追加する。
> New-NetNat -Name "Subnet-net" -InternalIPInterfaceAddressPrefix 192.168.55.0/24 ※一覧表示はこれ。 > Get-NetNat ※削除するときはこれ。 > Remove-NetNat -Name "Subnet-net"
ゲストOSでIPアドレスを設定する。ここでは、デフォルトゲートウェイとして192.168.55.1を設定している。
この接続の問題点はDNS。このスイッチはDNSをProxyしてくれないので、使用したいDNSを書いておく必要がある。
VMwareのようにこの仮想スイッチにDNSの機能を持たせようと思った場合、Windows Serverであれば、DNSを動作させて、そのDNSからローカルのDNSに聞きに行くようにすれば良いのだろうと思う(試していない)。
Windows 10の場合には、DNS Proxyのサービスを公開してくれている有志がいるので、これを使わせていただくのがよさそうだった。
Github / rtumaykin / hyperv-dnsproxy
ファイルの取り出し
今回、Ubuntu Liveを作成する環境を作ろうと思い立ったのがきっかけでHyper-Vに取り組んでいる。
できあがったLive CDイメージを外に取り出すための方法は2つ見つかった。
まず、拡張セッションや、リモートデスクトップ接続を使えば、フォルダの共有ができる。
多分、普通に使っている分には問題ないのだろうと思うけれど、1.6GB程あるLive CDイメージを取り出すと、しばしばコピー終了時にエラーが発生する。
理由はちゃんとは調べていないが、そういった特性なのだろうと割り切り。
次に、TeraTermのscp。これは至極安定している。
$ sudo apt install ssh
パスワード認証を許可する。
/etc/ssh/sshd_config
<omit>
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes ← 先頭の#を削除
#PermitEmptyPasswords no
<omit>
サービスを再起動して反映する。
$ sudo systemctl restart ssh
TeraTermで接続すると、ファイルを送り込んだり取り出したりできる。
ファイル→SCH SCRと選択し、表示されたダイアログで「Send」すればファイルを送り込むことができる。
この場合だと、接続している ubuntu ユーザーのホームディレクトリにファイルが送られる。
ISOイメージを取り出す場合は、「Receive」する。
その他、FTPやSMBマウントなどでもファイル転送はできると思うが、今回はこのくらいで。
VMwareとの共存
ネットワーク設定
Hyper-VもVMwareと同様、ネットワークアダプタを追加するようだった。
現在、VMware Workstation Playerによって、VMware Network Adapter VMnet1と、VMnet8が追加されている。
VMnet8がNATで使用される。
vmware docs / 仮想ネットワーク コンポーネントについて
今回の操作で、Hyper-Vの場合によって、vEthernet(Bridge)とvEthernet(Default Switch)が追加されている。
結果として、VMwareでブリッジ接続しているホストは、自動的に追加されたアダプタを選択した状態になり、ネットワーク接続が断続的になったり、動かなくなったりする。
そこで、vEthernetのネットワークアダプタのプロパティを開き、VMware Bridge Protocolのチェックを外す。
最初からある2つのアダプタはもちろん、スイッチを追加したらそれもチェックを外す。
これで、ブリッジの選択先から外として表示されなくなる。
同居した仮想マシン同士の通信
VMware Workstation PlayerとHyper-Vのホスト同士の接続は、こんな感じだった。
a から b への接続。試していないところは — 表示。
| a ＼ b | VMware Bridge | VMware NAT | Hyper-V Bridge | Hyper-V NAT |
|---|---|---|---|---|
| VMware Bridge | OK | — | NG | — |
| VMware NAT | OK | OK | — | — |
| Hyper-V Bridge | NG | — | — | — |
| Hyper-V NAT | OK | — | — | — |
調べはじめたのは、VMwareのBridge接続した仮想マシン(アーカイブミラー)に、Hyper-VのBridge接続した仮想マシン(UQUICK)から接続ができなかったから。
とても中途半端なのに書いているのは、途中で力尽きたから。
何か設定方法があるかもしれないけれど、調べるのも設定を変えるのも面倒なので、使えるところだけ使うという割り切り運用にした。
やったこと
ディスクのパフォーマンス改善
本編でも同じことを言っているけれども…VMware Playerと比較して、インストールの段階からパフォーマンスが悪すぎるから、色々と調べてみていた。
チェックポイント
チェックポイントという「いつでもある時点に環境を戻せる」機能が影響しているのでは？という情報があり、チェックポイントは作成しないように設定して確認してみた。
しかし、動作速度に影響はなかった。
自動停止アクションとウイルス対策
とにかくディスクが遅いので、色々と情報を探してみた。
Reddit / Hyper-V VM extremely slow – Disk usage always at 100%
自動開始アクションを停止させたり、Windows Defenderのリアルタイムスキャンから除外の設定をしたりと、色々状態を変えてdebootstrapを実行してみた(同じホストに立てているミラーからのインストール)。
| カーネル | 仮想マシン設定 自動開始アクション | 仮想マシン設定 自動停止アクション | 仮想ホスト RTスキャン | 仮想ホスト RTスキャン ディレクトリ除外 | 仮想ホスト RTスキャン 拡張子除外 | 計測結果 |
|---|---|---|---|---|---|---|
| インストール後そのまま | 何もしない | 仮想マシンを停止する | 無効 | D:\Hyper-V | vhdx | real 4m27.424s user 0m12.147s sys 0m6.972s |
| インストール後そのまま | 何もしない | 仮想マシンを停止する | 有効 | 未指定 | 未指定 | real 4m48.449s user 0m12.137s sys 0m6.597s |
| linux-azure | 何もしない | 仮想マシンを停止する | 有効 | 未指定 | 未指定 | real 4m35.499s user 0m12.138s sys 0m6.658s |
| I/Oスケジューラー none→deadline | 何もしない | 仮想マシンを停止する | 有効 | 未指定 | 未指定 | real 4m39.753s user 0m12.399s sys 0m6.389s ※HDDの音が凄い。 |
| (VMware) | (VMware) | (VMware) | 未指定 | 未指定 | real 0m18.646s user 0m15.728s sys 0m8.080s |
何の効果もなかったし、VMwareと比較すると15倍ぐらい遅かった。
IOスケジューラー
IOスケジューラーによっても違い起きることもあるようだ。
ubuntu wiki / IOSchedulers
ask ubuntu / How do I change to the noop scheduler? ← カーネルパラメーター elevator= は削除された
CLOVER / Ubuntu Linux 20.04 LTSについての、IOスケジューラーに関する情報を見てみる
# 状態を確かめる。 $ cat /sys/block/sda/queue/scheduler [none] mq-deadline # スケジューラーは2つ入っていて、このどちらかを選ぶ。 $ echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler
ディスクを作る時からパフォーマンスを考慮しておく必要があったらしい。
変更できないか…と思ったけれども、どうやら方法はなさそうなので、インストールからやり直し。
管理者でPowerShellを開き、以下のコマンドでディスクを作成する。
PS> New-VHD -Path D:\Hyper-V\HDD\CreateLive2.vhdx -SizeBytes 20GB -Dynamic -BlockSizeBytes 1MB
OSをインストールしてみた感じは遅そうだ。
そして、debootstrapの結果は…
real 4m35.467s
user 0m12.432s
sys 0m6.502s
何も違わない。
ということで
本編に書いたbarrer=0の設定をようやく見つけ、結果はこうなった。
real 0m22.766s
user 0m11.390s
sys 0m5.233s
これでも4秒も遅いわけだが、劇的な変化。
ちゃんとシャットダウン処理をせずにシステムが落ちたりすると、整合性がとれなくなるリスクがあるが、処理速度があまりに違いすぎるので採用。
ブリッジのIPv6を無効化 2022/04/09追記
ウチは、IPv4とIPv6のデュアルスタック環境にしている。IPv4の方は夕方頃から下りが物凄く混雑するため、V6プラスというオプションを付けてもらい、混雑している箇所をIPv6で迂回するようになっている。
このIPv6を導入するタイミングで、プロバイダーが提供するGUAだけでなく、宅内だけで利用するULAを構成し、IPv6用のDHCPを立てて運用している。
このDHCPは、メインPCに固定IPアドレスを払い出している。
つまり…
宅内で利用するIPv4アドレス
グローバルに使えるIPv6アドレス(GUA/自動構成)
宅内で利用するIPv6アドレス(ULA/DHCPにてIPアドレスを払い出す)
の3つのIPアドレス体系が適用された状態。
ULAを構成した狙いは、宅内のサービスにはローカルIPアドレスが返却できるようにすることだった。しかし、貸与されているルーターには「ローカルドメイン問い合わせテーブル」なる設定項目があり、ココに宅内サービスのドメインを登録しておけば、宅内に立てたDNSに名前解決にいく機能があったので、ULAはいらなかった…とはいえ、ULAは問題なく動いていた。
最近、PCの起動時に数秒固まる症状が現れ、何だろう？と思っていたのだが、割と普通にDNSへの問い合わせがタイムアウトする状態になっており、原因の1つになっていたようだ。
IPCONIFGコマンドでネットワークの状態を確認してみたところ、
- 本来、ホストに割り振るつもりで払い出していたULAが、作成したブリッジに割り当てられる。
- ホストにはULAが割り当てられていないのに、DNSのULAはセットされる。
という状態で、NSLOOKUPで問い合わせ先をULAにするとタイムアウトしていたのだった。
このことから、ブリッジのIPv6を無効にして、問題を解決したと思ったが…続く。
ブリッジのIPv4に固定IPアドレスを設定 2022/04/09追記
ブリッジのIPv6を無効化した後、IPCONFIG /RENEW6 “イーサネット n” 的なコマンドでIPv6のIPアドレスが払い出されることを確認し、OKとしたが、PCを再起動したらネットワークが詰まったような感じになった。
確認してみたところ、ブリッジがホストに割り振られるはずのIPv4アドレスを保持し、ホストでは使えなくなっていた。
仕方がないので、IPv4で開いているアドレスを割り当てておいた。
これでようやくブリッジによるホストへのネットワーク阻害攻撃は収まった。
さいごに
ディスクが遅い件について、Microsoftのサイトにもext3は遅くて、ext4にすべきだ、等の情報が書かれていたりする。
遅いことは認識しているようだけれども、本気で直す気はなさそうな説明っぷり、という印象。
簡単なチェックでは圧倒的なスピードに見えるように作られていて、使い込んでみると遅いという感じなのがちょっと嫌だなー。
AzureでLinuxを動かしたら、どんな性能になるんだろうか。なーんて、興味本位で思ったりして。
一方で、標準機能としてこれが盛り込まれているのは、業務で使用する場合にライセンス購入がいらないという意味で、とても優しい。
ウィークポイントをうまく避けながら付き合っていくことになりそうだ。
コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他