QEMUハイパーバイザーの下でVMWare ESXi 6.5を起動します

世界には素晴らしいVMWare ESXiハイパーバイザーがあり、すべてが順調ですが、動作可能なハードウェアの要件は非常に控えめです。 ESXiは基本的にソフトウェアRAID、100メガバイト、安価なギガビットネットワークカードをサポートしていません。そのため、適切な機器を購入することでしか動作しません。

ただし、クラスタリング、ライブマイグレーション、分散VSAN、分散ネットワークスイッチなど、複数のESXiホストがある場合、ESXiの最も「おいしい」ESXi機能が開きます。 この場合、テスト機器のコストはすでにかなりの量になる可能性があります。 幸いなことに、ESXiはネストされた仮想化、つまり、既に実行中のハイパーバイザーの下から実行する機能をサポートしています。 同時に、外部ハイパーバイザーはゲストがハードウェア仮想化にアクセスする必要があることを理解しており、ESXiはベアメタルでは動作しないことを知っています。 原則として、ESXiはメインハイパーバイザーとしても使用されます。この構成は、かなり前からVMWareでサポートされています。 QEMUハイパーバイザーを使用して、ESXiを起動しようとします。 ネットワークにはこれに関する指示がありますが、以下で見るように、それらは少し時代遅れです。



まず、実験を行うQEMUのバージョンを示します。

user@debian-pc:~$ QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-2) Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

現時点では最新バージョンですが、私の焦点は2.4.0でさえありました。

次に、ゲストが実際には存在しないマシン固有のレジスタを読み取ろうとする瞬間に、KVMモジュールの無礼な動作を無効にします。 デフォルトでは、これに応じてKVMはゲスト内で一般保護違反例外を生成します。これが、ゲストが青色（この場合はピンク色）のデススクリーンに表示される理由です。 ルートの下でやってみましょう：

 root@debian-pc:/> echo 1 > /sys/module/kvm/parameters/ignore_msrs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部のディストリビューションでは、kvmモジュールがデフォルトで必要なパラメーターとともにロードされますが、一部ではそうではありません。 いずれにせよ、dmesgの文字列を確認する必要があります

 user@debian-pc:~$ dmesg | grep kvm [ 6.266942] kvm: Nested Virtualization enabled [ 6.266947] kvm: Nested Paging enabled
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの行が存在しない場合は、/ etc / modprobe.d / kvm.confに行を追加します

 options kvm-amd npt=1 nested=1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして再起動します。 Intelプロセッサーの場合、行は次の形式を取ります。

 options kvm-intel ept=1 nested=1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

興味深いことに、dmesgで有効になっているネストされたページング/ネストされた仮想化についてはkvm-amdのみがレポートしますが、kvm-intelはレポートしません。



「額」の問題を解決してみましょう。VMWareWebサイトにアクセスして登録し、VMware-VMvisor-Installer-201701001-4887370.x86_64.isoの最新イメージをダウンロードしてください。



そのような構成では、ESXiが少なくともIDEを認識しないことを想定して、心構えず、16Gbで「フラッシュドライブ」の類似物を作成し、サポートされているe1000ネットワークカードを確保し、4GbにRAMを入れて（ESXiメモリーが少なくなり、起動しないことが保証されます）、インストールを実行しましょう-ドライブ：

 user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esx_6.5-1.qcow2 16G Formatting '/media/storage/VMs/esx_6.5-1.qcow2', fmt=qcow2 size=17179869184 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 user@debian-pc:~$ qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -hda /media/storage/VMs/esxi_6.5-1.qcow2 -cdrom /media/storage/iso/VMware-VMvisor-Installer-201701001-4887370.x86_64.iso -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、ここで最初の驚きに直面しています-ESXiはIDEドライブを検出するだけでなく、正常にインストールすることもできますが、インストールの27％で5分間ハングします。











ところで、インストールを開始する前に、次のメッセージが表示されます。







さて、プロセッサは明確です-ホストプロセッサのCPUIDをゲストにコピーする-cpuホストオプションを使用しました。所有しているホストプロセッサは、故人のFM1ソケットのAMD A8-3850 APUです。 ESXiが一般的にそのようなハードウェアに配置されているのは奇妙です。



8086は次のとおりです。100eは「Intel 82540EM Gigabit Ethernet Controller」チップの識別子で、しばらくの間サポートされていないと宣言されています。 動作しますが、テクニカルサポートは動作しません。



一般に、QEMUはさまざまなネットワークカードのエミュレーションをサポートしています。

 user@debian-pc:~$ qemu-system-x86_64 -device help < > Network devices: name "e1000", bus PCI, alias "e1000-82540em", desc "Intel Gigabit Ethernet" name "e1000-82544gc", bus PCI, desc "Intel Gigabit Ethernet" name "e1000-82545em", bus PCI, desc "Intel Gigabit Ethernet" name "e1000e", bus PCI, desc "Intel 82574L GbE Controller" name "i82550", bus PCI, desc "Intel i82550 Ethernet" name "i82551", bus PCI, desc "Intel i82551 Ethernet" name "i82557a", bus PCI, desc "Intel i82557A Ethernet" name "i82557b", bus PCI, desc "Intel i82557B Ethernet" name "i82557c", bus PCI, desc "Intel i82557C Ethernet" name "i82558a", bus PCI, desc "Intel i82558A Ethernet" name "i82558b", bus PCI, desc "Intel i82558B Ethernet" name "i82559a", bus PCI, desc "Intel i82559A Ethernet" name "i82559b", bus PCI, desc "Intel i82559B Ethernet" name "i82559c", bus PCI, desc "Intel i82559C Ethernet" name "i82559er", bus PCI, desc "Intel i82559ER Ethernet" name "i82562", bus PCI, desc "Intel i82562 Ethernet" name "i82801", bus PCI, desc "Intel i82801 Ethernet" name "ne2k_isa", bus ISA name "ne2k_pci", bus PCI name "pcnet", bus PCI name "rocker", bus PCI, desc "Rocker Switch" name "rtl8139", bus PCI name "usb-bt-dongle", bus usb-bus name "usb-net", bus usb-bus name "virtio-net-device", bus virtio-bus name "virtio-net-pci", bus PCI, alias "virtio-net" name "vmxnet3", bus PCI, desc "VMWare Paravirtualized Ethernet v3" <   >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、すべてがESXiで同等に機能するわけではありません。たとえば、ユーザーモードネットワークでのポート転送は正式にサポートされているe1000eでは機能せず、パケットの半分はvmxnet3で消えます。 それでは、e1000で停止しましょう。



VMを再起動すると、ハイパーバイザーが正常に起動したことがわかります。 実際、これですべてです。一部のマニュアルで推奨されているように、ESXiのQEMUにパッチを適用する必要はありません。



VMディスクはbtrfs上にあるため、nocow = onパラメーターを使用することに注意してください。btrfsは、コピーオンライトの概念を持つファイルシステムです。 これに、シンプロビジョニングされたqcow2形式のディスクもこの原則を実装しているという事実を追加すると、ディスクへの書き込み回数が倍増します。 nocow = onパラメーターを指定すると、qemu-imgはnocow属性を持つファイルを作成し、特定のファイルのbtrfsのコピーオンライトメカニズムをブロックします。



ユーザーネットワークモードでは、軽量のDHCPサーバーがVM内で実行されるため、アドレスを割り当てる必要はありませんが、ポートを転送する必要があります。 Ctrl + Alt + 1を押してQEMUコンソールに移動し、そこにコマンドを入力します

 > hostfwd_add tcp::4443-:443
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ポート443を仮想マシンのネットワークインターフェイスからホストのポート4443に転送します。 次に、ブラウザで次のように入力します



https：// localhost：4443 / ui



セキュリティ例外（もちろん、httpsに自己署名証明書を使用している間にESXi）を確認し、ハイパーバイザーのWebインターフェイスを見てみましょう。







驚くべきことに、ESXiインストーラーは8Gbもの空きディスク領域に「ストレージ」を作成しました。 まず、この便利なコンポーネントの開発はESXiの新しいバージョンよりも速いため、更新されたWebインターフェースを備えたパッケージをインストールします。 Ctrl + Alt + 1でQEMUコンソールに移動し、そこでポート22を転送します。

 > hostfwd_add tcp::2222-:22
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Ctrl + Alt + 2でハイパーバイザーコンソールに切り替え、F2を押します-トラブルシューティングオプション-SSHを有効にしてSSHクライアントに接続します。

 user@debian-pc:~$ ssh root@127.0.0.1 -p 2222 Password: The time and date of this login have been sent to the system logs. VMware offers supported, powerful system administration tools. Please see www.vmware.com/go/sysadmintools for details. The ESXi Shell can be disabled by an administrative user. See the vSphere Security documentation for more information.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一時ディレクトリに移動します

 [root@localhost:~] cd /tmp
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アップデートをダウンロード

 [root@localhost:/tmp] wget http://download3.vmware.com/software/vmw-tools/esxui/esxui-offline-bundle-6.x-5214684.zip Connecting to download3.vmware.com (172.227.88.162:80) esxui-offline-bundle 100% |************************************************************************************| 3398k 0:00:00 ETA
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれを置く

 [root@localhost:/tmp] esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-5214684.zip Installation Result Message: Operation finished successfully. Reboot Required: false VIBs Installed: VMware_bootbank_esx-ui_1.17.0-5214684 VIBs Removed: VMware_bootbank_esx-ui_1.8.0-4516221 VIBs Skipped:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、Webインターフェースのサイズは3メガバイトをわずかに超えています。



次に、仮想マシンの改善を試みます。 まず、ディスクコントローラーをIDEからAHCIに変更します。これは、QEMUでの1996 PIIX3コントローラーの実装が、いまだに禁止されているためです。 そして、AHCIコントローラ（Intel ICH9チップセットがエミュレートされます）は、第一に高速で、第二にNCQコマンドキューをサポートします。

 user@debian-pc:~$ qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device ide-drive,drive=drive0,bus=ahci.0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ハイパーバイザーのコンポーネントのロード時間を短縮しても、速度が向上したことは明らかです。 喜びのために、私たちはWebインターフェースに入り、...ディスクがないのはどうですか？ 「アダプター」タブにAHCIコントローラーがありますが、ディスクは検出されません。 しかし、ハイパーバイザーはどのようにロードしましたか？ 非常にシンプル-初期段階では、ブートローダーはBIOSを使用してディスクデータを読み取り、ディスクを直接確認する必要はありません。 コンポーネントがメモリにロードされた後、ローダーはそれらに制御を移し、ディスクにアクセスせずにハイパーバイザーの初期化が行われます。







場合によっては、ESXi 6.5はAHCIコントローラー上のディスクを認識しませんが、ESXi 6.0はこれらのディスクを認識しました。 Googleとそのような母親を使用して、 理由を見つけます：ESXi 6.5では、古いahciドライバーが完全に書き直されたvmw_ahciドライバーに置き換えられます。そのため、SSDによって多くの人が遅くなり、ドライブがなくなります。 記事のアドバイスによると、ハイパーバイザーで行います

 [root@localhost:~] esxcli system module set --enabled=false --module=vmw_ahci
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

再起動して...何も起こりません。 何が欲しかった？ ディスクがなく、構成を記録する場所がないため、変更は保存されませんでした。 IDEディスクに戻り、このコマンドを実行してからAHCIから起動する必要があります-その後、ディスクが検出されます。



ところで、Webベースのインターフェイスにアクセスすると、インストーラーによって作成された8ギガバイトの「ストレージ」が利用できなくなっていることがわかります。 そのため、さまざまなタイプのコントローラーに対して、VMWareにはさまざまなストレージ定義ポリシーがあります。 次に、ESXiがUSBフラッシュドライブにインストールされ、ストレージがハードドライブにある場合のシステムの実際の構成を表示してみましょう。 USB 3.0エミュレーションを使用します。

 user@debian-pc:~$ qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0 -netdev user,id=hostnet0, -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

USB 3.0ドライブも検出されません。 どうやら、ドライバーもここで書き換えられます。 まあ、私たちはすでに何をすべきか知っています。 ハイパーバイザーのコンソールに行き、そこに書きます

  esxcli system module set -m=vmkusb -e=FALSE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

システムが起動したら、ストレージ-デバイスに移動し、フラッシュドライブを確認します。 ところで、USB 3.0コントローラーnec-usb-xhciを使用すると、システムはich9-usb-ehci2を使用した場合よりもはるかに高速に起動します。







そのため、ESXi 6.5では、ESXi 6.0と比較して、少なくとも2つのディスクコントローラードライバーが再度上書きされます。 しかし、バージョン番号のドットの後の数字だけが変更されたように見えるでしょう。つまり、マイナーリリースです。



仮想マシンの構成に1 Tbディスクを追加すると、ハイパーバイザーを備えたディスクに加えて、本格的なストレージを作成できます。 ahciではなくusbドライブからシステムを起動するには、bootindexパラメーターを使用します。 通常、-bootパラメーターはブート順序を制御するために使用されますが、この場合は、ディスクが異なるコントローラーで「ハング」するため、役に立ちません。 同時に、プラットフォームを古い440fxチップセットから新しいQ35 / ICH9に置き換えます。

 user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-1.qcow2 1T user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンソールに入ります-ここに、ドライブがあります。







実験を続けましょう。ここで、いくつかのハイパーバイザーをネットワークに接続する必要があります。 一部のlibvirtは独立して仮想スイッチを作成し、それにマシンを接続します。これらの操作を手動で実行しようとします。



2つの仮想マシンがあるので、2つの仮想アダプターが必要です。

 user@debian-pc:~$ sudo ip tuntap add mode tap tap0 user@debian-pc:~$ sudo ip tuntap add mode tap tap1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、仮想スイッチが必要です。 長い間、これらの目的のためにbrctlユーティリティによって制御されるLinuxカーネルに組み込まれた仮想スイッチを使用することが慣習でした。 現在、Open vSwitch-仮想環境向けに特別に設計されたスイッチの実装を介して問題を解決するのが慣例となっています。 Open vSwitchには、VLAN、いくつかのスイッチ、そして最も興味深いことにOpenFlowテクノロジーを組み合わせるためのトンネリングプロトコル（GREなど）が組み込まれています。 つまり、L2 / L3フィルタリングルールを読み取り可能な形式でスイッチにロードできます。 以前は、フィルタリングにはiptables / ebtablesの使用が必要でしたが、彼らが言うように、良いことは「ebtables」が呼び出されないことです。



Open vSwitchがまだインストールされていない場合はインストールします。

 user@debian-pc:~$ sudo aptitude install openvswitch-switch
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

仮想スイッチを作成します。

 user@debian-pc:~$ sudo ovs-vsctl add-br ovs-bridge
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェイスを追加します。

 user@debian-pc:~$ sudo sudo ovs-vsctl add-port ovs-bridge tap0 user@debian-pc:~$ sudo sudo ovs-vsctl add-port ovs-bridge tap1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何が起こったのか見てみましょう：

 user@debian-pc:~$ sudo ovs-vsctl show e4397bbd-0a73-4c0b-8007-12872cf132d9 Bridge ovs-bridge Port "tap1" Interface "tap1" Port ovs-bridge Interface ovs-bridge type: internal Port "tap0" Interface "tap0" ovs_version: "2.6.2"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インターフェイスを実行します。

 user@debian-pc:~$ sudo ip link set tap0 up user@debian-pc:~$ sudo ip link set tap1 up user@debian-pc:~$ sudo ip link set ovs-bridge up
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のアドレスをスイッチインターフェイスに割り当てます。

 user@debian-pc:~$ sudo ip addr add 192.168.101.1 dev ovs-bridge
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

QEMUコマンドラインでネットワークタイプをユーザーからタップに変更するだけで、次のようになります。

 -netdev tap,ifname=tap,script=no,downscripot=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが機能します。



試してみましょう：

 user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2 -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ESXiコンソールに移動してアドレス192.168.101.2を割り当て、接続を確認します。

 user@debian-pc:~$ ping 192.168.101.2 PING 192.168.101.2 (192.168.101.2) 56(84) bytes of data. 64 bytes from 192.168.101.2: icmp_seq=1 ttl=64 time=0.582 ms 64 bytes from 192.168.101.2: icmp_seq=2 ttl=64 time=0.611 ms
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

...

およびESXiコンソールから-F2-テストネットワーク



すべてが機能し、pingが実行されます。



esxi_6.5-1.qcow2ドライブのコピーを作成し、2番目のESXiインスタンスを実行します。

 user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-2.qcow2 16G Formatting '/media/storage/VMs/esxi_6.5-2.qcow2', fmt=qcow2 size=17179869184 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on user@debian-pc:~$ dd if=/media/storage/VMs/esxi_6.5-1.qcow2 of=/media/storage/VMs/esxi_6.5-2.qcow2 bs=16M 31+1 records in 31+1 records out 531759104 bytes (532 MB, 507 MiB) copied, 10.6647 s, 49.9 MB/s user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-2-1T.qcow2 1T Formatting '/media/storage/VMs/esxi_6.5-2-1T.qcow2', fmt=qcow2 size=1099511627776 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-2.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-2-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2 -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、ホストから最初のゲストへのpingは、2番目のゲストへのpingを開始するまでしか行われません。 2番目のpingコマンドが中断された後、最初のゲストへのパケットは10秒後に送信を開始しますが、ゲスト間のpingはまったく送信されません。



Macアドレスを台無しにしたことは明らかです。実際、QEMUは、特に指定がない限り、すべてのタップアダプターに同じMACアドレスを割り当てます。



両方のESXiの電源を切り、一意のMacを表示して、再度起動します。

 user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2 -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=DE:AD:BE:EF:16:B6
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして別のコンソールで：

 user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-2.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-2-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2 -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=DE:AD:BE:EF:C3:FD
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

驚いたことに、pingの問題は解決していません。さらに、arpコマンドは、ハイパーバイザーのMACアドレスが変更されていないことを示しています。 ESXiでネットワークがどのように構成されているかを思い出してください。物理ネットワークカードは「判読不能モード」であり、ポートとして仮想スイッチに接続されています。 このスイッチに接続されている別のポートはvmkernelです。これは、ハイパーバイザーの観点からはネットワークカードです。 ESXiのインストール時に、システム管理者を混乱させないために、物理ネットワークカードのハードウェアアドレスがvmkernelに複製されます。 その後、インターフェイスを削除して再作成するか、物理カードのアドレスが変更されたためにvmkernelを再構成する必要があることをハイパーバイザーに示すことによってのみ変更できます。



最初の方法：



削除：

 esxcfg-vmknic -d -p pgName
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは作成します：

 esxcfg-vmknic -a -i DHCP -p pgName
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 esxcfg-vmknic -a -i xxxx -n 255.255.255.0 pgName
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の方法：

 esxcfg-advcfg -s 1 /Net/FollowHardwareMac
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの方法の大きな違いは、最初の方法ではハイパーバイザーを再起動する必要がなく、2番目の方法ではハイパーバイザーを再起動する必要があることです。



これらの簡単な操作を完了すると、同じネットワーク上に2つのハイパーバイザーを取得できます。



これで、vCenterをインストールし、「ライブマイグレーション」を確認できます。 しばらくの間、vCenterはLinuxおよび関連サービスが搭載された仮想マシンイメージとして利用できました。 これは、インストールしようとするオプションです。 VMware-VCSA-all-6.5.0-5178943.isoイメージを取得し、ホストOSにマウントし、vcsc-ui-installer \ lin64ディレクトリからインストーラーを実行し、ウィザードの指示に従ってイメージを展開します。 仮想マシンは10 GbのRAMを必要とするため、ホストシステムに16 Gb以上を搭載することをお勧めします。 しかし、私のイメージは12 GbのRAMで向きを変え、利用可能なメモリをすべて使い果たし、システムをスワップに落としました。







VCSAをインストールした後、タイプadministrator@mydomain.tlbの資格情報とSSOを構成するときに指定したパスワードを使用してWebインターフェイスにアクセスします。 その後、両方のホストをvCenterに追加し、ライブマイグレーションが機能する最も単純なクラスターを取得します。 両方のホストのネットワークカードでvMotionをセットアップし、TestVM仮想マシンを作成し、ホスト間で移動できることを確認して、ホストとストレージの両方を変更します。







ところで、6.0までのESXiの以前のバージョンでは、行を追加しないと仮想マシンをネスト仮想化モードで起動できませんでした

 vmx.allowNested = TRUE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

彼女の設定ファイルに。 ESXi 6.5はこれを必要とせず、仮想マシンは問題なく起動します。



結論として-小さなライフハック。 Veeam Backup and ReplicationからFastSCPを使用できない一方で、VMディスクファイルをESXiストレージからバックアップサーバーにコピーする必要があるとします。 古き良きrsyncが役立ちます。ESXiで実行されるバイナリファイルを見つけるだけです。 残念ながら、バージョン3.0.9までのrsyncでは、VMFSボリューム上の大きなファイルが正しく処理されないためにバグがあるため、rsyncバージョン3.1.0を使用する必要があります。 とアップ。 ここで取ることができます 。