2021/11/08(月) [n年前の日記]
#1 [ubuntu][linux] QEMU+KVMを少し触ってた
Ubuntu Linux 20.04 LTS x64 をインストールしてあるサブPC(CPU: AMD A8-3850)上で、仮想マシン QEMU + KVM を少しだけ触ってた。
◎ 参考ページ。 :
_QEMU をつかって仮想マシンを作成する - Qiita
_Ubuntu 20.04 LTS : KVM : 仮想マシンの基本操作 : Server World
_KVM をインストールして設定する - Qiita
_UbuntuにQEMU仮想化ソフトウェアをインストールするにはどうすればよいですか? | Ubunlog
_Ubuntu 20.04へKVMのインストールと、bridge接続の構成 - Symfoware
_ubuntu で kvm qemu インストール - それマグで!
_QEMU をインストールし,起動する(Ubuntu 上)
_Ubuntu で Raspbian システムを起動(QEMU, qemu-rpi-kernel を使用)
_Ubuntu20.04にKVMをインストールする方法
_KVMのインストールと仮想ブリッジの作成 | Server-bff.net
_ubuntu 18.04 上でkvm仮想マシンを動作させるまでの最低限の手順 - Qiita
_Ubuntu 20.04 LTS : KVM : 仮想マシンの基本操作 : Server World
_KVM をインストールして設定する - Qiita
_UbuntuにQEMU仮想化ソフトウェアをインストールするにはどうすればよいですか? | Ubunlog
_Ubuntu 20.04へKVMのインストールと、bridge接続の構成 - Symfoware
_ubuntu で kvm qemu インストール - それマグで!
_QEMU をインストールし,起動する(Ubuntu 上)
_Ubuntu で Raspbian システムを起動(QEMU, qemu-rpi-kernel を使用)
_Ubuntu20.04にKVMをインストールする方法
_KVMのインストールと仮想ブリッジの作成 | Server-bff.net
_ubuntu 18.04 上でkvm仮想マシンを動作させるまでの最低限の手順 - Qiita
◎ KVM が使える状態か調べる。 :
cpu-checker というパッケージをインストールすると、kvm-ok というツールが使えるようになるらしい。これで KVM が利用できる環境かどうかを確認できる。
CPU情報その他を調べていくことでも確認できる模様。
AMD A8-3850 も、一応 KVM を使えるようだなと…。古いCPUだから無理かなと思ったけど大丈夫そう。
sudo apt install cpu-checker
$ kvm-ok INFO: /dev/kvm exists KVM acceleration can be used
CPU情報その他を調べていくことでも確認できる模様。
$ lscpu | grep -Ei "(vt-x|amd-v)" 仮想化: AMD-V $ grep -E "(vmx|svm)" /proc/cpuinfo flags: ... svm ... svm_lock ... $ lsmod | grep kvm kvm_amd 98304 0 ccp 86016 1 kvm_amd kvm 663552 1 kvm_amd
AMD A8-3850 も、一応 KVM を使えるようだなと…。古いCPUだから無理かなと思ったけど大丈夫そう。
◎ 必要なパッケージをインストール。 :
各ページを参考にして色々インストール。何がどういうパッケージなのかは把握してない…。
念のために再起動。
サービスとして動いてるか確認。Active になっていればいいらしい。
sudo apt install qemu-kvm qemu libvirt-clients libvirt-daemon-system libvirt-daemon virtinst bridge-utils libguestfs-tools virt-top virt-manager virt-viewer sudo apt install qemu-system qemu-system-arm
念のために再起動。
sudo reboot
サービスとして動いてるか確認。Active になっていればいいらしい。
$ sudo systemctl is-active libvirtd active or $ systemctl status libvirtd
◎ グループに追加。 :
自分のアカウントを、kvmグループ、libvirtグループ、libvirt-qemuグループに追加。
今回、libvirt には既に追加されていて、kvm、libvirt-qemu の追加だけをすれば良かった。
グループに追加されているか確認。
今回、libvirt には既に追加されていて、kvm、libvirt-qemu の追加だけをすれば良かった。
$ sudo gpasswd -a $(whoami) libvirt $ sudo gpasswd -a $(whoami) kvm $ sudo gpasswd -a $(whoami) libvirt-qemu or $ sudo adduser `id -un` libvirt $ sudo adduser `id -un` kvm $ sudo adduser `whoami` libvirt-qemu
グループに追加されているか確認。
$ groups $(whoami)
◎ ブリッジ接続とやらを追加。 :
巷の記事を眺めるとブリッジ接続を追加してる場合が多いので一応追加してみる。ただ、後述するけど、結局このブリッジ接続とやらは使わなかった。
_KVMのインストールと仮想ブリッジの作成 | Server-bff.net
_Ubuntu 20.04へKVMのインストールと、bridge接続の構成 - Symfoware
今回の環境では、enp1s0 というのがNICにつけられた名前らしい。
netplan なるものの設定をして、ブリッジ接続とやらを増やす。
オリジナルの設定ファイルをバックアップ。
設定ファイルを編集。
設定を反映。
br0 が追加された。
しかし、OSを再起動したら、vmnet* が消滅した…。これはよろしくない気がする…。
設定ファイル、/etc/netplan/01-network-manager-all.yaml の内容を元に戻すことにした。
_KVMのインストールと仮想ブリッジの作成 | Server-bff.net
_Ubuntu 20.04へKVMのインストールと、bridge接続の構成 - Symfoware
$ ip a 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 ... 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 ... 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 ... 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 ... 5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 ... 6: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 ...
今回の環境では、enp1s0 というのがNICにつけられた名前らしい。
netplan なるものの設定をして、ブリッジ接続とやらを増やす。
オリジナルの設定ファイルをバックアップ。
$ cd /etc/netplan/ $ ls -al 合計 20 drwxr-xr-x 2 root root 4096 8月 6 2019 . drwxr-xr-x 187 root root 12288 11月 8 05:43 .. -rw-r--r-- 1 root root 104 8月 6 2019 01-network-manager-all.yaml $ sudo cp /etc/netplan/01-network-manager-all.yaml /etc/netplan/01-network-manager-all.yaml.orig
設定ファイルを編集。
sudo vi /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system network: ethernets: enp1s0: dhcp4: yes dhcp6: yes bridges: br0: interfaces: [enp1s0] dhcp4: yes dhcp6: yes version: 2 # renderer: NetworkManager
設定を反映。
$ sudo netpaln apply
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 ... 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000 ... 3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 ... 4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 ... 5: vmnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 ... 6: vmnet8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 ... 7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 ...
br0 が追加された。
しかし、OSを再起動したら、vmnet* が消滅した…。これはよろしくない気がする…。
設定ファイル、/etc/netplan/01-network-manager-all.yaml の内容を元に戻すことにした。
$ sudo vi /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system network: version: 2 renderer: NetworkManager
◎ 仮想マシンを作成できない。 :
デスクトップ上で仮想マシンマネージャを起動して、仮想マシンを新規作成しようとしたけれど、Debian 11 bullseye や Ubuntu 18.04 LTS のインストール用isoを指定しても次に進めない…。OSの種類を自動検出せずに Generic と打ち込んで選ばないといかんらしい。
仮想ディスクの作成でもハマった。容量を指定するだけではダメで、手動で保存場所を作成しないといかんようだなと…。/var/lib/libvirt/images/ 以下に仮想ディスクイメージを作成した。今回は /var/lib/libvirt/images/Ubuntu1804/ubuntu1804.qcow2 を作成。
仮想ディスクの作成でもハマった。容量を指定するだけではダメで、手動で保存場所を作成しないといかんようだなと…。/var/lib/libvirt/images/ 以下に仮想ディスクイメージを作成した。今回は /var/lib/libvirt/images/Ubuntu1804/ubuntu1804.qcow2 を作成。
◎ ゲストOSが動かない。 :
ゲストOSとして Ubuntu Linux 18.04 LTS をインストールしてみたけれど、起動時のスプラッシュ画面?のまま次の画面に移行しない…。処理が遅くて時間がかかっているのか、それとも無限ループに陥っているのか…。
◎ アンインストールした。 :
せっかくインストールしたゲストOSも起動しないし、そもそも QEMU + KVM を今後使うかどうかも微妙な気がしてきたので、アンインストールしておいた。
以下の警告が出てきた。
OS再起動後、手作業で各フォルダを削除。
$ sudo apt purge qemu-kvm qemu libvirt-clients libvirt-daemon-system libvirt-daemon virtinst bridge-utils libguestfs-tools virt-top virt-manager virt-viewer qemu-system qemu-system-arm $ sudo apt autoremove
以下の警告が出てきた。
dpkg: 警告: libvirt-daemon-system の削除中、ディレクトリ '/var/lib/libvirt/qemu' が空でないため削除できませんでした dpkg: 警告: libvirt-daemon-system の削除中、ディレクトリ '/var/lib/libvirt/images' が空でないため削除できませんでした dpkg: 警告: libvirt-daemon-system の削除中、ディレクトリ '/etc/libvirt' が空でないため削除できませんでした
OS再起動後、手作業で各フォルダを削除。
[ ツッコむ ]
#2 [ubuntu][linux] VirtualBoxのゲストOSが遅い
Ubuntu Linux 20.04 LTS x64 をインストールしてあるサブPC上で、VirtualBox を使って Ubuntu Linux 18.04 LTS x64 をインストールしようとして少しハマった。とにかく遅い…。どうもパッケージ linux-headers-* をインストールしようとするところで時間がかかっているようで…。30分ぐらいかかってようやく先に進む感じで。
ググってみたら、ストレージの設定がよろしくなかったらしい。
_apt - Ubuntu in Virtual box is upgrading packages terribly slow - Ask Ubuntu
_[Vagrant]HDD使用時にディスクI/Oが非常に遅い時にすべき事 | akamist blog
_VirtualBoxのストレージがめちゃくちゃ遅かった理由がわかった - Days of Speed(2019-11-05)
「ホストのI/Oキャッシュを使う」にチェックを入れれば改善するのだとか。もちろん、デメリットもあるわけだけど…。
ググってみたら、ストレージの設定がよろしくなかったらしい。
_apt - Ubuntu in Virtual box is upgrading packages terribly slow - Ask Ubuntu
_[Vagrant]HDD使用時にディスクI/Oが非常に遅い時にすべき事 | akamist blog
_VirtualBoxのストレージがめちゃくちゃ遅かった理由がわかった - Days of Speed(2019-11-05)
「ホストのI/Oキャッシュを使う」にチェックを入れれば改善するのだとか。もちろん、デメリットもあるわけだけど…。
[ ツッコむ ]
以上、1 日分です。