Windows

Hyper-VでUbuntu20.04を使う

会社で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
<omit>

割り当てるメモリーの固定

クイック作成した仮想マシンは、メモリーは2GBと定義しているけれども、実際には7GBが割り当てられていた。

先日16GBメモリーのPCで2台目の仮想マシンを起動しようとしたところ、メモリー不足で起動ができないことがあり、4GBマシン2台が何故立ち上がらないのかと調べてみたら、勝手に割り当てるメモリーを増やしているのが分かった次第。

設定項目を確認すると「動的メモリ」というのがあり、これが柔軟にメモリーを上下させる機能のようなんだけれども、稼働中の仮想マシンからメモリーを回収して、起動しようとしているPCに割り当てる…的な動作はできないようだ。少ないメモリーで複数台の仮想マシンを起動する、的なことは結局のところできない上に、メモリー設計をちゃんとしても最初のOSが想定以上のメモリを勝手にとって返してくれないデメリットしかなかった。

仮想マシンが利用するメモリーを定義して、動的メモリのチェックを外すことで、計画通りにメモリーを使うようになる。

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 Quick10348.13 MB/sec142.97 MB/sec1.7 GB/s202 MB/s
Hyper-V ISO install + barrier=011958.15 MB/sec305.46 MB/sec1.2 GB/s191 MB/s
VMware Workstation Player 166832.52 MB/sec216.13 MB/sec382 MB/s196 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の違いがあるから、切り替えても起動しないことは確か。余計なトラブルを生まない知恵なのかもしれない。

クイック作成で作られる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

問題なし。

表示倍率のリセット方法

ちょっと画面を小さく表示させたいと思って、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で拡張セッションに関する設定したところ、ちゃんと使えるようになった。
でも、メイン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 \ bVMware
Bridge
VMware
NAT
Hyper-V
Bridge
Hyper-V
NAT
VMware BridgeOKNG
VMware NATOKOK
Hyper-V BridgeNG
Hyper-V NATOK

とても中途半端なのに書いているのは、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-Vvhdxreal 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を動かしたら、どんな性能になるんだろうか。なーんて、興味本位で思ったりして。

一方で、標準機能としてこれが盛り込まれているのは、業務で使用する場合にライセンス購入がいらないという意味で、とても優しい。
ウィークポイントをうまく避けながら付き合っていくことになりそうだ。

コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他