これで作られるもの
ベアメタルマシン上でProxmox VEを独自のハイパーバイザーとして実行し、NVMeドライブ全体でZFSミラーを構成し、ゲストに実アドレスを渡すブリッジを持ち、ネストされた仮想化が有効になっていることを確認します。つまり、このマシン上のゲストは、それ自体がゲストを実行できます。
ネストが、仮想インスタンスではなくベアメタルでこれを行う理由です。他の誰かのハイパーバイザー内で予測可能な結果でネストすることはできません。BM-Eでは、当社のハイパーバイザーが介在しません。IPMI、電源ボタン、ボードが得られます。そこで何を実行するかはお客様の決定です。
始める前に
- BM-E: 32 Zen 4コア、256 GB ECC、4つのNVMeドライブ、8つのIPv4アドレス。IPMIはVPN経由で到達可能で、サポートがマシン引き渡し時に設定します。
- 注文時に選択したProxmox VE 8、またはパネルからアップロードしたカスタムISO。両方のルートは同じインストーラーに到達します。
- マシンを必要としない30分間。最初のステップで数回再起動するためです。
1. インストール
管理VPN経由でコンソールに接続し、ISOをマウントして起動します。ディスク選択画面で4つのNVMeデバイスすべてを選択し、zfs (RAID10)を選択して、詳細オプションを開きます：
ashiftを12に設定します。これは4Kセクターに正しい値で、後でプールを再構築せずに変更できません。compressをlz4に設定します。コアのわずかなコストで、通常はスペースの3分の1を返します。hdsizeを減らして、残りをゲストストレージ用に残します。ルートプールがすべてを所有させたい場合を除きます。
パネル詳細から管理アドレスとゲートウェイを設定し、ホスト名としてマシンの完全修飾名を使用します。2回の再起動後、ログインプロンプトとポート8006のWebインターフェースが表示されます。
2. リポジトリとパッケージ
エンタープライズリポジトリはサブスクリプションなしでは失敗し、処理するまですべてのapt updateを乱雑にします：
rm -f /etc/apt/sources.list.d/pve-enterprise.sources
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-community.list
apt update && apt full-upgrade -y
apt install -y ifupdown2 chrony zfsutils-linux
reboot3. ZFS用メモリ
そうしないとARCはRAMの半分まで成長し、ゲストを実行するのが仕事であるマシンでは、そのメモリにはより良い用途があります：
echo "options zfs zfs_arc_max=34359738368" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all256 GBマシン上の32ギガバイトのARCは、ゲストを飢えさせることなくキャッシュに十分な余裕を残します。適用するには再起動するか、できない場合はechoを使用して/sys/module/zfs/parameters/zfs_arc_maxにライブで設定します。
4. ネットワーキング
8つのアドレスは多くないので、ゲストはプライベートブリッジ上に置かれ、パブリックアドレスが必要なものだけがルーティングされます。/etc/network/interfacesを編集します：
auto lo
iface lo inet loopback
auto enp1s0f0
iface enp1s0f0 inet static
address <public address>/24
gateway <gateway>
auto vmbr0
iface vmbr0 inet static
address 10.20.0.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
post-up iptables -t nat -A POSTROUTING -s 10.20.0.0/24 -o enp1s0f0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s 10.20.0.0/24 -o enp1s0f0 -j MASQUERADE
iface vmbr0 inet6 static
address 2001:db8:1a2b:20::1/64IPv6はアドレス変換を必要としません。マシンにルーティングされた/64は本当にルーティングされているため、ブリッジ上のゲストにそのアドレスを割り当てると、直接インターネットに到達します。2つのファミリー間のこの非対称性はエレガントではありませんが、私たちが住むアドレス空間の正直な形です。
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/80-pve.conf
echo "net.ipv6.conf.all.forwarding = 1" >> /etc/sysctl.d/80-pve.conf
ifreload -a5. ネストされた仮想化
cat /sys/module/kvm_amd/parameters/nested現在のカーネルでは、これはすでに1を出力します。0を出力する場合：
echo "options kvm-amd nested=1" > /etc/modprobe.d/kvm-amd.conf
update-initramfs -u && rebootネストには、ゲストが機能を持っていることを認めるCPUを見る必要もあります。つまり、プロセッサタイプはhostでなければなりません。それ以外は、仮想化拡張がマスクされた合成CPUモデルを提示し、内部ハイパーバイザーはこれに言及しないエラーで起動を拒否します。
6. ゲスト
cd /var/lib/vz/template/iso
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2
qm create 100 --name inner --memory 16384 --cores 8 --cpu host \
--net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-single --ostype l26 \
--agent enabled=1 --machine q35 --bios ovmf
qm set 100 --efidisk0 local-zfs:1
qm importdisk 100 debian-13-genericcloud-amd64.qcow2 local-zfs
qm set 100 --scsi0 local-zfs:vm-100-disk-1,discard=on,ssd=1
qm set 100 --boot order=scsi0
qm set 100 --ipconfig0 ip=10.20.0.100/24,gw=10.20.0.1
qm set 100 --sshkeys /root/.ssh/authorized_keys
qm set 100 --ciuser admin
qm start 100discard=onとssd=1を組み合わせると、ゲスト内の削除が、追跡を失ったスペースとして蓄積されるのではなく、プールに返されます。
7. ファイアウォール
ポート8006のWebインターフェースは、公に到達可能であるべきではありません。データセンター・レベルで、管理元のアドレスに制限します。WireGuardガイドのトンネルエンドポイントが明らかな候補です：
cat > /etc/pve/firewall/cluster.fw <<EOF
[OPTIONS]
enable: 1
policy_in: DROP
[RULES]
IN SSH(ACCEPT) -source 10.7.0.0/24
IN ACCEPT -source 10.7.0.0/24 -dport 8006 -proto tcp
IN ACCEPT -p icmp
EOF
systemctl restart pve-firewall検証
ホストから：
pveversion -v | head -3
zpool status rpool
zpool list -o name,size,alloc,free,frag,cap
arc_summary | head -12プールはONLINEを2つのミラーペアで報告し、ARCターゲットはマシンの半分ではなく設定した32ギガバイトにあります。
次に、このビルドの実際の目的です。ゲストにログインして、与えられたプロセッサを確認します：
ssh [email protected]
lscpu | grep -E "Model name|Virtuali"
grep -c svm /proc/cpuinfoモデル名は実際のEPYCパーツである必要があり、仮想化行はAMD-Vを報告する必要があります。3番目のコマンドのゼロは、プロセッサタイプがhostではないことを意味し、以下のすべてが失敗します。
次に、マシン内でマシンを実行します：
apt install -y qemu-system-x86 qemu-utils cpu-checker
kvm-ok
wget https://dl-cdn.alpinelinux.org/alpine/v3.22/releases/x86_64/alpine-virt-3.22.0-x86_64.iso
qemu-system-x86_64 -enable-kvm -m 2048 -cdrom alpine-virt-3.22.0-x86_64.iso -nographickvm-okがアクセラレーションを使用できることを出力し、続いてAlpineが数秒でログインプロンプトに到達する起動（クロールではなく）が検証です。ネストがない場合、同じコマンドは完全に拒否するか、ソフトウェアでエミュレートして約20分の1の速度になり、それは明確です。
最後に、インターフェースが外部から閉じていることを確認します：
curl -m5 -k https://<public address>:8006/ ; echo "exit $?"接続タイムアウトが正しい答えです。
その後
ZFS上のスナップショットは、それらが発散するまで無料です。したがって、夜間のzfs-auto-snapshotスケジュールはほぼコストがかからず、どのバックアップポリシーよりも多くのマシンを救ってきました。ベアメタルでの再構築は即日ですが、再構築は空のマシンを返します。これは、あなたのマシンを返すこととは別物です。