Ubuntu KVM および libvirtd サーバー BMS 環境
手順と推奨事項は、 Ubuntu 20.04.x のインストールに有効であり、Ubuntu 22.04.x でも機能する可能性があります。LACP ブリッジのサポートについては、Ubuntu 16.04 は「 Linux ブリッジと VM インターフェイスの VM 作成後の変更」の章で使用されている調整をサポートしていないことがわかっています。
導入前の準備
オプション: KVM/QEMU をまだインストールしていない場合はインストールします
以下のコマンドは、KVM ハイパーバイザーのインストール方法と必要なチェックの実行方法を示しています。ルートディレクトリを使用していることを確認してください。
sudo -i cd /root lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Codename: focal uname -a Linux aide-glb-srv-2 5.4.0-88-generic #99-Ubuntu SMP Thu Sep 23 17:29:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # MANDATORY CHECK FOR NEEDED CPU FLAGS grep 'flags' /proc/cpuinfo | head -n1 | grep -E 'vmx|svm' flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a rdseed adx smap intel_pt xsaveopt cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts md_clear flush_l1d apt-get update apt-get -y upgrade apt-get install -y qemu-kvm libvirt-daemon-system libvirt-clients net-tools bridge-utils virtinst virt-top genisoimage usermod -aG libvirt $USER usermod -aG kvm $USER #chown libvirt-qemu /var/lib/libvirt/images # MANDATORY CHECK kvm-ok INFO: /dev/kvm exists KVM acceleration can be used
オプション:DHCPサーバーでbr0-bridgeを作成します
インストールが完了すると、ハイパーバイザーは192.168.122.0/24プレフィックスにデフォルトの virbr0 Linuxブリッジを自動的に作成します。このブリッジは、残りのネットワーク インターフェイスを NAT から発信し、DHCP サーバーのリースを管理します。OOB 管理用に vJunos-switch VM fxp0 インターフェイスを接続できます。このデフォルトのvirbr0 Linuxブリッジの制限は、DHCPリース配布物がランダムで予測できないことです。
ラボ サーバー用に、追加の br0 Linux ブリッジを作成することをお勧めします。このLinuxブリッジは、192.168.10.0/24プレフィックスを使用して同じものをコピーするために、外部インターフェイスをNATする必要があります。
cat <<EOF >br0network.xml <network> <name>br0network</name> <forward mode='nat'/> <bridge name='br0' stp='off' delay='0'/> <ip address='192.168.10.1' netmask='255.255.255.0'/> </network> EOF virsh net-destroy br0network virsh net-undefine br0network virsh net-define --file /root/br0network.xml virsh net-autostart br0network virsh net-start br0network virsh net-list Name State Autostart Persistent ----------------------------------------------- br0network active yes yes default active yes yes brctl show bridge name bridge id STP enabled interfaces br0 8000.5254001a8a15 no br0-nic virbr0 8000.52540018df7d yes virbr0-nic
DHCP を使用して fxp0 の vEX スイッチに固定 IP を割り当て、スイッチに SSH 接続できるようにしました。標準の virbr0-bridge は、192.168.122.0/24 の範囲からランダムな IP アドレスを割り当てます。代わりに、単純なDHCPサーバーを作成して、br0 Linuxブリッジ上の既知のMACアドレスに192.168.10.0/24の範囲で静的リースを提供します。次に、最初のインターフェイスの MAC アドレスの 1 つを使用して vJunos-switch 仮想マシンを起動し、定義済みの IP アドレスを fxp0 インターフェイスに割り当てます。
cat <<EOF > /root/br0-dnsmasq.conf strict-order user=root pid-file=/tmp/br0-dnsmasq.pid except-interface=lo bind-dynamic interface=br0 dhcp-range=192.168.10.150,192.168.10.250,255.255.255.0 dhcp-no-override dhcp-authoritative dhcp-option=3,192.168.10.1 dhcp-option=6,8.8.8.8 dhcp-host=52:54:00:6c:3c:00,aos-server,192.168.10.200 dhcp-host=52:54:00:6c:3c:01,sw-1,192.168.10.201 dhcp-host=52:54:00:6c:3c:02,sw-2,192.168.10.202 dhcp-host=52:54:00:6c:3c:03,sw-3,192.168.10.203 dhcp-host=52:54:00:6c:3c:04,sw-4,192.168.10.204 dhcp-host=52:54:00:6c:3c:05,sw-5,192.168.10.205 dhcp-host=52:54:00:6c:3c:06,sw-6,192.168.10.206 dhcp-host=52:54:00:6c:3c:07,sw-7,192.168.10.207 dhcp-host=52:54:00:6c:3c:08,sw-8,192.168.10.208 dhcp-host=52:54:00:6c:3c:09,sw-9,192.168.10.209 dhcp-host=52:54:00:6c:3c:0a,sw-10,192.168.10.210 dhcp-host=52:54:00:6c:3c:0b,sw-11,192.168.10.211 dhcp-host=52:54:00:6c:3c:0c,sw-12,192.168.10.212 dhcp-host=52:54:00:6c:3c:0d,sw-13,192.168.10.213 dhcp-host=52:54:00:6c:3c:0e,sw-14,192.168.10.214 dhcp-host=52:54:00:6c:3c:0f,sw-15,192.168.10.215 dhcp-host=52:54:00:6c:3c:10,sw-16,192.168.10.216 dhcp-host=52:54:00:6c:3c:99,wan-router,192.168.10.99 EOF dnsmasq --conf-file=/root/br0-dnsmasq.conf
Linuxブリッジを作成してVM間のネットワークリンクをシミュレートする
vJunos スイッチ仮想マシンの fxp0 インターフェイスを接続する場合は、デフォルトの virbr0 または新しい br0 Linux ブリッジを使用します。他のすべてのリンクには新しいブリッジが必要なため、デバイス間に仮想リンクを作成します。この例では、ブリッジ名は Junos OS インターフェイスの命名規則をコピーしようとします。
ip link add name ge000 type bridge
ip link set ge000 up
ip link add name ge001 type bridge
ip link set ge001 up
ip link add name ge002 type bridge
ip link set ge002 up
ip link add name ge003 type bridge
ip link set ge003 up
# OPTIONAL: check your Linux-bridges
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.525400938f81 no br0-nic
vnet0
ge000 8000.000000000000 no
ge001 8000.000000000000 no
ge002 8000.000000000000 no
ge003 8000.000000000000 no
virbr0 8000.525400ffc947 yes virbr0-nic
vJunosスイッチのJunos OSデフォルト設定
次の主な理由により、vJunosスイッチ仮想マシンの起動時に実行されるカスタムJunos OS設定を含める必要がある場合があります。
- Juniper Apstraなどの管理システムがログインするための既知のパスワードで、root/スーパーバイザーアカウントを作成します。これにより、ローカルのDHCPサーバーがカスタマイズされた設定をプッシュする必要がなくなり、SSHログインをサポートしてデバッグが向上します。
- Mist Cloudに採用設定を適用して、新しいスイッチがインベントリに表示されるようにします。
- 新しいラボの開始時に、以前のラボから既存の有効な設定を読み込みます。
カスタマイズされた工場出荷時デフォルト
以下は、以下の構成でファイル juniper.conf を作成する際にロードする最小Junos OS構成の例です。
- ユーザー名=
root - パスワード=
ABC123 - fxp.0からDHCPリースを取得する予定です
- すべてのインターフェイスでLLDPを有効にする
cat <<EOF >juniper.conf system { host-name spine1; root-authentication { encrypted-password "\$6\$DOvFAxW9\$HpxgOaGEe5L6MtDJqbWepS5NT6EW23rCuu69gwwGVFr7BpzY2MHS34mPrR0LKRqoGI19tRgpz3vFJkEueW9mQ1"; ## SECRET-DATA } services { ssh { root-login allow; protocol-version v2; } } name-server { 8.8.8.8; 9.9.9.9; } arp { aging-timer 5; } syslog { file interactive-commands { interactive-commands any; } file messages { any notice; authorization info; } } } interfaces { fxp0 { unit 0 { family inet { dhcp force-discover; } } } } protocols { lldp { interface all; } lldp-med { interface all; } } EOF
オプション:Mist Cloudに採用するJunos OS設定の追加
このステップでは、Junos OS設定を追加して、スイッチがMist Cloudに自動的に表示されるようにします。
- [Organization -> Inventory] に移動します。
- [スイッチ(Switches)] を選択し、[スイッチの採用(Adopt Switches)] をクリックします。
- [ クリップボードにコピー] をクリックします。
- 任意のエディターから
adopt-template.txtファイルを開き、収集した情報をこのファイルに貼り付けます。次に、ファイルを保存して閉じます。vi adopt-template.txt
手記：同じMist Cloud導入コードを使用して、同じ組織内のすべてのスイッチをオンボーディングすることができます。
- テンプレートを使用して情報を変換し、別の Junos OS 設定形式で変更します。まず、bash シェル コマンドを使用して、ファイル
adopt-template.txtから 5 つの変数を抽出する必要があります。MISTVAR1=`cat adopt-template.txt | sed 's/\"//g' | grep "set system login user mist authentication encrypted-password" | awk '{print $8}'` MISTVAR2=`cat adopt-template.txt | sed 's/\"//g' | grep "set system login user mist authentication ssh-rsa" | awk '{print $8 " " $9}'` MISTVAR3=`cat adopt-template.txt | sed 's/\"//g' | grep "set system services outbound-ssh client mist secret" | awk '{print $8}'` MISTVAR4=`cat adopt-template.txt | sed 's/\"//g' | grep "set system services outbound-ssh client mist" | grep "port" | awk '{print $7}'` MISTVAR5=`cat adopt-template.txt | sed 's/\"//g' | grep "set system services outbound-ssh client mist" | grep "device-id" | awk '{print $8}'`
このステップでは、set コマンドに依存しない Junos OS 設定を追加し直します。
cat <<EOF >>juniper.conf
system {
login {
user mist {
class super-user;
authentication {
encrypted-password "$MISTVAR1";
ssh-rsa "$MISTVAR2";
}
}
}
services {
outbound-ssh {
client mist {
device-id "$MISTVAR5";
secret "$MISTVAR3";
keep-alive {
retry 12;
timeout 5;
}
services netconf;
$MISTVAR4 {
port 2200;
retry 1000;
timeout 60;
}
}
}
}
}
EOF
# review the final config
cat juniper.conf
VM の Junos OS 設定による仮想ディスクの作成
- vJunos-switchサポートサイトから
make-config.sh元のbashスクリプトを使用して、カスタム設定を読み込むためのHDイメージを作成します。.png)
- リンクからイメージをダウンロードします。たとえば、「 https://webdownload.juniper.net/swdl/dl/anon/site/1/record/168885.html」のように入力します。
画像が見つからない場合は、以下のコピーを使用してください。
#!/bin/bash # # make-config.sh # # Copyright (c) 2023, Juniper Networks, Inc. # All rights reserved. # # Create a config metadisk from a supplied juniper.conf to attach # to a vJunos VM instance # usage() { echo "Usage : make-config.sh <juniper-config> <config-disk>" exit 0; } cleanup () { echo "Cleaning up..." umount -f -q $MNTDIR losetup -d $LOOPDEV rm -rfv $STAGING rm -rfv $MNTDIR } cleanup_failed () { cleanup; rm -rfv $2 exit 1 } if [ $# != 2 ]; then usage; fi STAGING=`mktemp -d -p /var/tmp` MNTDIR=`mktemp -d -p /var/tmp` mkdir $STAGING/config cp -v $1 $STAGING/config qemu-img create -f raw $2 1M LOOPDEV=`losetup --show -f $2` if [ $? != 0 ]; then cleanup_failed; fi mkfs.vfat -v -n "vmm-data" $LOOPDEV if [ $? != 0 ]; then echo "Failed to format disk $LOOPDEV; exiting" cleanup_failed; fi mount -t vfat $LOOPDEV $MNTDIR if [ $? != 0 ]; then echo "Failed to mount metadisk $LOOPDEV; exiting" cleanup_failed; fi echo "Copying file(s) to config disk $2" (cd $STAGING; tar cvzf $MNTDIR/vmm-config.tgz .) cleanup echo "Config disk $2 created" exit 0 make-config.shを使用して、カスタマイズした構成を含む qcow2-Image を作成します。./make-config.sh juniper.conf myconfig.qcow2 'juniper.conf' -> '/var/tmp/tmp.S9uwgranof/config/juniper.conf' Formatting 'myconfig.qcow2', fmt=raw size=1048576 mkfs.fat 4.1 (2017-01-24) mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows /dev/loop7 has 64 heads and 32 sectors per track, hidden sectors 0x0000; logical sector size is 512, using 0xf8 media descriptor, with 2048 sectors; drive number 0x80; filesystem has 2 12-bit FATs and 4 sectors per cluster. FAT size is 2 sectors, and provides 502 clusters. There is 1 reserved sector. Root directory contains 512 slots and uses 32 sectors. Volume ID is 9136e65a, volume label vmm-data . Copying file(s) to config disk myconfig.qcow2 ./ ./config/ ./config/juniper.conf Cleaning up... removed '/var/tmp/tmp.S9uwgranof/config/juniper.conf' removed directory '/var/tmp/tmp.S9uwgranof/config' removed directory '/var/tmp/tmp.S9uwgranof' removed directory '/var/tmp/tmp.iz7I2RJJAI' Config disk myconfig.qcow2 created ls -l myconfig.qcow2 -rw-r--r-- 1 root root 1048576 Apr 19 19:46 myconfig.qcow2
- KVM VM の最終宛先に構成イメージをコピーします。
cp myconfig.qcow2 /var/lib/libvirt/images/spine1-config.qcow2
- 新しい vJunos-switch VM を作成する際は、以下に示す太字の線を VM virt-install 設定に挿入します。例は 、Proxmox仮想環境の章で説明されています。
. --disk path=/var/lib/libvirt/images/spine1.qcow2,cache=writeback,bus=virtio \ --disk path=/var/lib/libvirt/images/spine1-config.qcow2 \ --import \ .
virt-install CLI を使用した vJunos-switch VM の導入
vJunosスイッチ仮想マシンごとに、システムが書き込むためのベースイメージのコピーが個別に必要です。以下の設定では、KVMバッキングファイル方式を使用して、元のイメージから変更して読み取り、変更してイメージを作成します。この方法では、VM の起動が高速化され、ストレージが節約されます。場合によっては、ファイルを /etc/libvirt/qemu.conf 変更して、自分自身をユーザーおよびグループとして追加する必要があります。次に、 sudo systemctl restart libvirtd を実行してこの機能を使用します。
qemu-img create -b vjunos-switch-23.1R1.8.qcow2 -f qcow2 /var/lib/libvirt/images/spine1.qcow2
バックアップ ファイルでは、常に各 VM のイメージをコピーできる必要があります。
cp vjunos-switch-23.1R1.8.qcow2 /var/lib/libvirt/images/spine1.qcow2
最後に、以下の構成で、太字のパラメータを変更せずに、vJunos-switch 仮想マシンを正常に起動できます。VM の最初のイーサネット インターフェイスは常に fxp0 です。MAC アドレスを設定し、静的 DHCP リースとして 192.168.10.201 を割り当てるように DHCP サーバーを構成したら、後でリモート シェルを直接起動できます。
virt-install -n spine1 -r 5120 --vcpus=4 \
--sysinfo smbios,system.product=VM-VEX \
--hvm --cpu IvyBridge,require=vmx \
--disk path=/var/lib/libvirt/images/spine1.qcow2,cache=writeback,bus=virtio \
--import \
-w bridge=br0,model=virtio,mac="52:54:00:6c:3c:01" \
-w bridge=ge000,model=virtio \
-w bridge=ge001,model=virtio \
-w bridge=ge002,model=virtio \
-w bridge=ge003,model=virtio \
--nographics --noautoconsole
Starting install...
Domain creation completed.
virsh domiflist spine1
Interface Type Source Model MAC
-----------------------------------------------------------
vnet1 bridge br0 virtio 52:54:00:6c:3c:01
vnet2 bridge ge000 virtio 52:54:00:ac:2f:63
vnet3 bridge ge001 virtio 52:54:00:90:ea:79
vnet4 bridge ge002 virtio 52:54:00:24:0f:1d
vnet5 bridge ge003 virtio 52:54:00:11:45:56
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.525400938f81 no br0-nic
vnet0
vnet1
brtest 8000.000000000000 no
ge000 8000.fe5400ac2f63 no vnet2
ge001 8000.fe540090ea79 no vnet3
ge002 8000.fe5400240f1d no vnet4
ge003 8000.fe5400114556 no vnet5
virbr0 8000.525400ffc947 yes virbr0-nic
# OPTIONAL: check the xml config create with the official documentation
virsh dumpxml spine1
# OPTIONAL: open a console to the VM to see what it does
virsh console --force spine1
virt-manager GUI を使用した vJunos-switch VM の導入
virt-manager GUI を使用して vJunos-switch をインストールする場合、いくつかの XML ベースの設定ファイルを手動で変更する必要があります。そのため、GUIはこのVMに何のメリットも提供しません。
- 次に示すように、ベース VM のコピーを libvirtd イメージディレクトリーに取得します。
cp vjunos-switch-23.1R1.2.qcow2 /var/lib/libvirt/images/spine1.qcow2
- [ Edit -> Preferences ] をクリックして、この VM の XML 編集を有効にします。
- [ XML 編集を有効にする] を選択します。
- [File] -> [New Virtual Machine] を選択します。
- [インストール用に既存のディスクイメージをインポート]を選択します。
- [ 参照] をクリックします。
- コピーした画像を選択し、[ ボリュームの選択]をクリックします。
- [OS の 一般的なデフォルト ] を選択し、[ 進む] をクリックします。
- [+] をクリックして構成します。
- メモリ=
5120 - CPU=
4
- メモリ=
- 次に、次のように構成します。
- 名前=
spine1 - [ インストール前に構成をカスタマイズする] を選択します。
- 今のところ、 [仮想ネットワーク 'br0network': NAT ] を選択します。最初のインターフェイス(fxp0)のネットワーク選択は、NAT ネットワークである必要があります。
- 「 終了」をクリックします。
- 名前=
- [ CPU] をクリックします。
ホストCPUが設定されています。[ XML ] をクリックすると、他のオプションは必要ないため、後で構成を変更できます。
- 最初のインターフェイスのデバイスモデルを virtio に変更します。
- インターフェイスの add 関数を使用して新しいネットワーク インターフェイスを追加し、次のように構成します。
- ネットワークソース=
Bridge ge000 - チェックを外す=
MAC address - デバイスモデル=
virtio
- ネットワークソース=
- ステップ13を繰り返して、ネットワークソース
Bridge ge001, Bridge ge002とBridge ge003.を追加します
- 必要に応じて、下図で黄色でハイライトされているデフォルトのインターフェイスとオプションは、vJunosスイッチ仮想マシンに必要ないため、削除できます。
- [OS 情報] を選択し、次に [編集する XML] を選択します。以下に示すように、
<os>と</os>の間のすべてを削除し、強調表示された行に置き換えます。置き換えられた構成では、仮想マシンが vMX としてではなく vEX9214 として動作するように、特別な BIOS コマンドが指示されます。
- 以下に示すように、次の設定を挿入します。
<sysinfo type='smbios'> <system> <entry name='product'>VM-VEX</entry> </system> </sysinfo> <os> <type arch='x86_64' machine='pc-i440fx-focal'>hvm</type> <boot dev='hd'/> <smbios mode='sysinfo'/> </os>置き換えられた設定は、下の図で黄色で強調表示されています。
- 上の図に示すように、
<cpuから次の設定を挿入します。<cpu mode='custom' match='exact' check='full'> <model fallback='forbid'>IvyBridge</model> <feature policy='require' name='ibpb'/> <feature policy='require' name='md-clear'/> <feature policy='require' name='spec-ctrl'/> <feature policy='require' name='ssbd'/> <feature policy='require' name='vmx'/> <feature policy='require' name='hypervisor'/> <feature policy='require' name='arat'/> <feature policy='require' name='xsaveopt'/> </cpu>置き換えられた設定は、下の図で黄色で強調表示されています。
- 以下に示すように、次の設定を挿入します。
- 「適用」をクリックし、「インストールの開始」をクリックします。
インストール プロセスには 3 分かかる場合があり、VM のログインを求められます。
LinuxブリッジとVMインターフェイス VM作成後の変更
VM の起動後、インターフェイスと Linux ブリッジの構成を変更する必要があります。「 展開前の準備」の章のデフォルト設定で作成したブリッジは、EVPN VXLAN ファブリックに適用できます。
デフォルトのLinuxブリッジは以下をサポートしていません。
- LLDPメッセージトランスポート、つまり、リンクネイバーは表示されません。
- LACP 802.3ad メッセージ転送のため、LAG の構築ができません。
- MTU が大きいため、VXLAN メッセージのフラグメント化が発生する。VXLAN を使用する場合、ファブリックの MTU は、接続されているクライアントよりも 50 バイト以上大きい必要があります。接続されているデスクトップ仮想マシンとすべてのファブリック リンクを、同じデフォルト MTU が 1500 で、トランスポート リンクは常に 50 バイトを追加します。ICMP Pingなどの小さなパケットはうまく機能しますが、クライアントが1500バイトの完全なMTUを使用する場合は機能しません。
- 802.1X 有線クライアント認証はブロックされます。
そのため、これらの機能をサポートするには、VM の作成後に仮想インターフェイスと Linux ブリッジを変更する必要があります。この変更により、仮想EVPN VXLANファブリックをスムーズに構築できます。
- 次のコマンドを使用して bash スクリプトを作成し、必要なすべての機能を実行します。
rm -f vm-bridge-update.sh touch vm-bridge-update.sh chmod 777 vm-bridge-update.sh vi vm-bridge-update.sh
- 以下の設定をコピーしてエディターに貼り付けます。次に、保存して閉じます。
#!/bin/bash virsh domiflist $1 | tail -n +4 > /tmp/vmbridgelist.txt sed -i '/^$/d' /tmp/vmbridgelist.txt # cat /tmp/vmbridgelist.txt while IFS= read -r line do INTERFACE=`echo $line | awk '{ print $1 }'` NTYPE=`echo $line | awk '{ print $2 }'` BRIDGE=`echo $line | awk '{ print $3 }'` if [ "$NTYPE" == "bridge" ]; then # change MTU to higher value RUNME="ip link set dev "$INTERFACE" mtu 9200" echo $RUNME eval $RUNME # enable LLDP and 802.1x on bridge RUNME="echo 65528 > /sys/class/net/"$BRIDGE"/bridge/group_fwd_mask" echo $RUNME eval $RUNME # enable LACP on link RUNME="echo 16388 > /sys/class/net/"$INTERFACE"/brport/group_fwd_mask" echo $RUNME eval $RUNME fi done < /tmp/vmbridgelist.txt num=0 while IFS= read -r line do INTERFACE=`echo $line | awk '{ print $1 }'` NTYPE=`echo $line | awk '{ print $2 }'` BRIDGE=`echo $line | awk '{ print $3 }'` if [ "$NTYPE" == "bridge" ]; then MTU=`cat /sys/class/net/$BRIDGE/mtu` if [ "$MTU" != "9200" ]; then echo 'Warning! Bridge:'$BRIDGE' did not follow new MTU setting of interface:'$INTERFACE' check other interfaces attached to same bridge and correct please!' num=1 fi fi done < /tmp/vmbridgelist.txt exit $num - このスクリプトをデモ VM で実行すると、変更の適用に必要なコマンドを監視できます。
./vm-bridge-update.sh core1 ip link set dev vnet4 mtu 9200 echo 65528 > /sys/class/net/exfabric1/bridge/group_fwd_mask echo 16388 > /sys/class/net/vnet4/brport/group_fwd_mask ip link set dev vnet5 mtu 9200 echo 65528 > /sys/class/net/uplink1/bridge/group_fwd_mask echo 16388 > /sys/class/net/vnet5/brport/group_fwd_mask ip link set dev vnet6 mtu 9200 echo 65528 > /sys/class/net/fabric1/bridge/group_fwd_mask echo 16388 > /sys/class/net/vnet6/brport/group_fwd_mask ip link set dev vnet7 mtu 9200 echo 65528 > /sys/class/net/fabric2/bridge/group_fwd_mask echo 16388 > /sys/class/net/vnet7/brport/group_fwd_mask Warning! Bridge:uplink1 did not follow new MTU setting of interface:vnet5 check other interfaces attached to same bridge and correct please!
特定のインターフェイスでアップグレードされていないMTUについて、意図的に警告を発しています。この警告は、Linux ブリッジの MTU が、接続されているネットワーク インターフェイスの中で常に最小であることを意味します。したがって、単一のブリッジに接続されているすべてのインターフェイスをアップグレードしてください。それ以外の場合、MTUの変更は実装されません。
手記：
このスクリプトは、VM の最初のインターフェイス (通常は fxp0) を意図的にアップグレードしません。このインターフェースを含める場合は、2 行目を「virsh domiflist $1 |tail -n +3 > /tmp/vmbridgelist.txt" です。
手記：
Linuxブリッジの調整は、Ubuntu20.04以降でのみ機能します。
オプション: KVM サーバーの最適化
Ultra Kernel Samepage マージ カーネル
ウルトラカーネルをサポートするカーネルを使用すると、複数のvJunosスイッチ仮想マシンを起動するときに、標準のKSMサポートと比較して30〜40%のメモリを節約できます。これは、ラボや、デフォルトでこのカーネルを含むEVE-NGなどのシステムにとって有益です。上位カーネルをサポートしていないUbuntu 20.04.xでシステムが動作している場合は、次の構成を使用して、公式のGitHubリポジトリからそのようなカーネルをビルドできます。
手記：
BIOSでセキュアブートが無効になっていることを確認します。そうでない場合、署名されていないカーネルはロードされません。
lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.5 LTS Release: 20.04 Codename: focal uname -r 5.4.0-135-generic sudo apt-get install -y build-essential flex bison git libssl-dev libncurses-dev libelf-dev zstd git clone https://github.com/dolohow/uksm.git
- ブラウザに 「https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/refs/ 」と入力します。
通常の
5.4.xカーネルがサーバーにインストールされている場合は、次のコマンドを実行します。rm -rf focal git clone --depth 1 --single-branch --branch Ubuntu-5.4.0-135.152 https://git.launchpad.net/\~ubuntu-kernel/ubuntu/+source/linux/+git/focal cd focal patch -p1 < ~/uksm/v5.x/uksm-5.4.patch
- ハードウェア使用可能スタック (HWE) をサポートする
5.15.xなどの新しいカーネルがサーバーにインストールされている場合は、次のコマンドを実行します。rm -rf focal git clone --depth 1 --single-branch --branch Ubuntu-hwe-5.15-5.15.0-57.63_20.04.1 https://git.launchpad.net/\~ubuntu-kernel/ubuntu/+source/linux/+git/focal cd focal patch -p1 < ~/uksm/v5.x/uksm-5.15.patch
- カーネルのバージョンに関係なく、次の構成に進み、USKM カーネルをビルドしてインストールします。
make oldconfig Enable KSM for page merging (KSM) [Y/n/?] y Choose UKSM/KSM strategy > 1. Ultra-KSM for page merging (UKSM) (NEW) 2. Legacy KSM implementation (KSM_LEGACY) (NEW) choice[1-2?]: 1 # patches for this kernel to compile scripts/config --disable DEBUG_INFO sed -i 's/CONFIG_SYSTEM_TRUSTED_KEYS="debian/canonical-certs.pem"/CONFIG_SYSTEM_TRUSTED_KEYS=""/g' .config sed -i 's/CONFIG_SYSTEM_REVOCATION_KEYS="debian/canonical-revoked-certs.pem"/CONFIG_SYSTEM_REVOCATION_KEYS=""/g' .config cat .config | grep _KEYS # The below command is slower but maybe used for debugging when building the kernel fails # make deb-pkg LOCALVERSION=-uksm make -j$(nproc) deb-pkg LOCALVERSION=-uksm ls -la ../*deb -rw-r--r-- 1 root root 11650688 Jan 7 13:11 ../linux-headers-5.4.212-uksm_5.4.212-uksm-1_amd64.deb -rw-r--r-- 1 root root 62563988 Jan 7 13:12 ../linux-image-5.4.212-uksm_5.4.212-uksm-1_amd64.deb -rw-r--r-- 1 root root 1072104 Jan 7 13:11 ../linux-libc-dev_5.4.212-uksm-1_amd64.deb cd .. sudo dpkg -i linux-headers-5.4.212-uksm_5.4.212-uksm-1_amd64.deb sudo dpkg -i linux-image-5.4.212-uksm_5.4.212-uksm-1_amd64.deb sudo update-grub sudo reboot - サーバーが再び起動したら、新しいカーネルで実行されているかどうかを確認します。
uname -r 5.4.212-uksm
セキュリティの緩和策をオフにする
手記：
サーバーが運用環境にある場合、またはインターネット経由でアクセス可能な場合は、これらの手順は避けてください。セキュリティ チェックを修正して、ラボの CPU パフォーマンスを向上させることができます。警告が表示されます。
CPU パフォーマンスの 20% の損失を回避するには、メルトダウン/スペクターの脆弱性に対するすべての軽減策を無効にします。このサーバーは、異なるユーザーからの VM をホストしません。ラボ内のすべての VM を管理し、それが一般に提供されている実稼働グレードのシステムではないため、セキュリティよりもパフォーマンスが優先されます。
#we ARE already a VM so to have most speed turn off security patches #add mitigations=off to your kernel parameters like below sudo vi /etc/default/grub . . GRUB_CMDLINE_LINUX_DEFAULT="" GRUB_CMDLINE_LINUX="mitigations=off" # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains . . sudo update-grub # make latest kernel >=5.4 active through reboot of VM sudo reboot # you should see the below now with disabled security tweaks grep . /sys/devices/system/cpu/vulnerabilities/* | egrep -i 'meltdown|spectre' /sys/devices/system/cpu/vulnerabilities/meltdown:Vulnerable /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers /sys/devices/system/cpu/vulnerabilities/spectre_v2:Vulnerable, IBPB: disabled, STIBP: disabled