ICTSC2024 本戦 問題解説: [AZW] VM 畑でつかまえて
問題文
概要
A さんはオンラインオークションサイトで念願のラックサーバを手に入れた!莫大なサイズのメモリが搭載されているため、VM をどれだけ作っても枯渇しないだろうと考えるとワクワクが止まらない様子。早速 VM を 2 つ作ってひとまず両者の間で通信をさせてみようと考え、A さんはまずテンプレートとなる VM を作成した。次に、テンプレートを 2 回クローンして 2 つの VM vm1 と vm2 を作成した。その後、bridge interface をそれぞれの VM で 1 つずつ作成し、IP アドレスをアサインするための設定を書いた。
早速、相手の VM と通信できるか試してみたところ、なぜか繋がらなかった。ネットワークインターフェイスに割り当てた IP アドレスの設定を何度見直しても間違いはないと A さんは言う。
ちなみに、A さんは設定より規約という考え方と systemd-networkd が好きで、ip コマンドを叩いたセットアップは極力したくないらしい。
A さんのワクワクが止まらないうち(具体的には、ICTSC2024 本戦競技時間中)に、原因究明と解決策の適用、およびそれらの報告を行いなさい。
前提条件
/etc/systemd/network
以下でファイルの作成・編集・削除を行わないことip
コマンドや netplan、NetworkManager などの、systemd-networkd 以外を用いたネットワークインターフェイスの設定をしないこと- 再起動後に終了状態が継続していること
初期状態
vm1 で $ ping 10.0.1.1
を実行しても返答がない。また、vm2 で $ ping 10.0.1.0
を実行しても返答がない。
終了状態
vm1 で $ ping 10.0.1.1
を実行すると返答がある。また、vm2 で $ ping 10.0.1.0
を実行すると返答がある。
また、再起動後にも上記の状態が継続していることが確認できる。
解説
この問題では、ネットワークインターフェイス br0 の MAC アドレスが vm1 と vm2 で同一であるために ping が失敗していました。
br0 の MAC アドレスが同一になる原因は、vm1 と vm2 の /etc/machine-id
が同一であることです。/etc/machine-id
は、ホストごとに異なる値が格納されていることが期待されますが、VM のディスクを単純にクローンすると、クローン元と先で同一の値が格納されたままになってしまうことがあります。今回の例では、br0 の MAC アドレスがカーネルによって /etc/machine-id
に依存して算出されることがあいまって MAC アドレスの衝突が発生していました。
原因より、/etc/machine-id
を異なるものに変更すればよいということがわかります。そのため、少なくとも一方の VM 上で $ sudo truncate -s 0 /etc/machine-id; sudo systemd-machine-id-setup; sudo reboot
を実行することにより、解決できました。これは再起動後にも終了状態を維持する操作の一例です。
採点基準
- MAC アドレスの衝突を解消し、終了状態を満たしている: +100 点
講評
前提条件「/etc/systemd/network
以下でファイルの作成・編集・削除を行わないこと」に違反している報告書が幾つか見受けられました。
VM をクローンして利用する際には /etc/machine-id
の重複に注意すべきだとホットステージ中に気づいたことから急遽作成された問題でした。