hidemium's blog

日々学んだことをアウトプットする。

踏み台サーバーを経由したUbuntuへのリモートデスクトップ接続

前回、踏み台サーバーを経由してVisual Studio CodeのRemote Developmentで接続する方法を記事にしました。今回は、踏み台サーバーを経由してリモートデスクトップ接続について書いてみようと思います。

hidemium.hatenablog.com

構成

  • Windows 10 (接続元)
  • Ubuntu 22.04 (踏み台サーバー)
    • public IP: 192.168.100.100/24
    • internal IP: 192.168.10.100/24
  • Ubuntu 22.04 (接続先)
    • internal IP: 192.168.10.201/24

接続先のサーバーのセットアップ

接続のサーバーは、Ubuntu Desktopとしてインストールを行います。

isoファイルからインストールするか、Ubuntu ServerからUbuntu Desktopのインストールを行いますが、今回はisoファイルからインストールを行いました。

リモートデスクトップ接続の接続先となるサーバーのインターフェイスにプライベートネットワークのIPアドレスを設定しておきます。

踏み台サーバーのインターフェイスの設定は前回と同じです。

xrdpのインストール

Ubuntuには、SettingsにSharing(共有)という機能があります。

こちらの機能は、RDPを使った画面をミラーする機能になり、Windowsリモートデスクトップ接続とは異なり、サーバーにコンソール接続してログインしたい状態ではないと操作ができません。

ログアウトした状態で、リモートデスクトップ接続を行いたい場合は、xrdpを利用します。

Ubuntu 24.04では、リモートログイン機能が入りましたが、Ubuntu 22.04ではないため、リモートデスクトップ接続できるようにxrdp をインストールします。

sudo apt install xrdp

xrdpを使用する場合、X Window SystemXorgが利用され、起動処理の中でGNOMEのデスクトップ環境が選択されて起動します。

  1. ユーザーがRDPクライアントでXorgセッションで接続。
  2. xrdpがstartwm.shを実行。
  3. startwm.sh内で、/etc/X11/Xsessionが呼び出される。
  4. /etc/X11/XsessionがGNOMEデスクトップ環境を起動し、リモートデスクトップGUIを提供。

デスクトップ環境を.xsessionrcで設定することも可能ですが、デフォルトで /usr/share/xsessions/ubuntsu-xorg.desktopGNOMEが指定されてそうでした。

ssh configの設定

接続先の踏み台サーバーが用意できたため、Local Port ForwardingでRDP接続できるように、以下のように C:\Users\User Name\.ssh/config ファイルを編集します。

Host bustion
  HostName 192.168.100.100
  User UserName
  ForwardAgent yes
  LocalForward 13389 192.168.10.201:3389

Windowsからのリモートデスクトップ接続

PowerShellsshコマンドで接続して、Local Port Forwardingができるか確認してみます。

ssh先で何もしないため、-Nオプションを指定しておきます。

ssh -N bustion

Windowsリモートデスクトップ接続を起動し、コンピューターに localhost:13389 を入力します。

接続をするとxrdpのログイン画面が表示されるため、SessionにXorg、usernameとpasswordにUbuntuのログイン情報を入力します。

ログインすると、Dockが表示されず、右上にActivitiesのみ表示されます。

gnome-extensionsコマンドでdockを有効にすると、左側にDockが表示されるようになります。

$ gnome-extensions list
ding@rastersoft.com
ubuntu-appindicators@ubuntu.com
ubutu-dock@ubuntu.com
$ gnome-extensinos enable ubuntu-dock@ubuntu.com

踏み台サーバーを経由したVisual Studio CodeのRemote Developmentの設定

以前、Visual Studio CodeのRemote Developmentの設定方法について記事にしました。今回は、踏み台サーバーを経由して開発環境に接続する方法を記載してみようと思います。

hidemium.hatenablog.com

構成

  • Windows 10 (Visual Studio Code)
  • Ubuntu 22.04 (踏み台サーバー)
    • public IP: 192.168.100.100/24
    • internal IP: 192.168.10.100/24
  • Ubuntu 22.04 (接続先)
    • internal IP: 192.168.10.200/24

踏み台サーバーと接続先のサーバーの設定

踏み台サーバーのインターフェイスに外部接続用のIPアドレスとプライベートネットワークのIPアドレスを設定しておきます。

Visual Studio Codeの接続先となるサーバーのインターフェイスにプライベートネットワークのIPアドレスを設定しておきます。

それぞれにWindowsで生成した公開鍵を設定しておきます。

公開鍵の設定は、cloud-initを使うとログインせずに設定できます。

hidemium.hatenablog.com

ssh configの設定

以下のように C:\Users\User Name\.ssh/config ファイルを編集します。

Host bustion
  HostName 192.168.100.100
  User UserName
  ForwardAgent yes

Host dev
  HostName 192.168.10.200
  User UserName
  ProxyJump bustion

ForwardAgentは、秘密鍵を踏み台サーバーに置かずにアクセスするためのssh agent機能を使う設定となります。

ProxyJumpは、踏み台サーバーを経由してターゲットサーバーにssh接続するオプションで、以前はProxyCommandが使われていましたが、ProxyJumpはシンプルに記述ができます。

Visual Studio CodeのRemote Developmentの設定 (Windows 10側)

右下のグリーンの >< ボタンをクリックすると、メニューが表示されるため、 Connect to Host をクリックします。

ssh configに設定した踏み台サーバーを経由した接続先のホスト名をクリックします。

platformに Linux を選択します。

vscodeのファイルがインストールされて、接続が完了します。

Local Port Forwardingの利用

Local Port Forwardingを利用して、8000番のポートに届いた通信を踏み台サーバーを経由して接続先のサーバーの8000番ポートへ転送ができるか試してみます。

通信を確認するために、pythonでWebサーバーを起動してみます。

python3 -m http.server 8000

以下のように C:\Users\User Name\.ssh/config ファイルを編集すると、Local Port Forwardingができます。

Host bustion
  HostName 192.168.100.100
  User UserName
  ForwardAgent yes

Host dev
  HostName 192.168.10.200
  User UserName
  ProxyJump bustion
  LocalForward 8000 localhost:8000

PowerShellsshコマンドで接続して、Local Port Forwardingができるか確認してみます。

ssh先で何もしないため、-Nオプションを指定しておきます。

ssh -N dev

ブラウザからlocalhost:8000にアクセスし接続できることを確認します。

python3 -m http.server 8000
127.0.0.1 - - [01/Dec/2024 00:26:49] "GET / HTTP/1.1" 200 -

また、vscodeでもLocal Port Forwardingができます。

ssh configでLocalForwardの設定を戻し、vscodePORTS を開いて、 Forward a Port ボタンをクリックします。

同様に、ブラウザからlocalhost:8000にアクセスし接続できることを確認します。

Windowsのインストール後にVMware 準仮想化 SCSI コントローラに変更する

Windows Serverにて、LSI Logic SASでインストール後にVMware 準仮想化 SCSI コントローラ(PVSCSI)に変更を行った場合、OSの起動ができくなることがあり、起動ができるようにするためいくつか試してみたので書いてみようと思います。

構成

  • vCenter 8.0U3
  • ESXi 8.0U3
  • Windows Server 2019

一般的な方法

通常、LSI Logic SASでインストール後にVMware 準仮想化 SCSI コントローラ(PVSCSI)に変更を行った場合には、以下のKBが公開されています。

VMware 準仮想化 SCSI (PVSCSI) アダプタを使用するようにディスクに構成する

流れとしては、以下のようになります。

  1. VMware Toolsをインストールする
  2. 一時的な利用のため新しい SCSI コントローラ (PVSCSI) を作成する
  3. 一時的な利用のため新しい1GB ディスク (SCSI 1:0) を作成する
  4. 仮想マシンをパワーオンし、ディスク管理で新しい1GBのディスクが見えていることを確認する
  5. シャットダウンする
  6. 一時的なSCSIコントローラー(PVSCSI)とディスク(SCSI 1:0)を削除する
  7. 既存のSCSIコントローラーをLSI Logic SASからVMware 準仮想化に変更する
  8. 仮想マシンをパワーオンし、OSが起動することを確認する

こちらの方法だと確実に起動することが可能ですが、一時的なSCSIコントローラーやディスクを作成したり、電源のオンオフが必要だったりします。

試した方法

まずは、LSI Logic SASでインストール後にVMware 準仮想化 SCSI コントローラ(PVSCSI)に変更を行った場合にどのような挙動になるか確認します。

何度も試せるように、スナップショットを取得しておきます。

  1. シャットダウン
  2. 既存のSCSIコントローラーをLSI Logic SASからVMware 準仮想化に変更する
  3. 仮想マシンをパワーオン

上記の操作を行うと、OSが起動時に以下のinaccessible boot deviceというメッセージが表示され、OSの起動に失敗します。

PVSCSIを認識させる

この状態だと、OSの起動時にPVSCSIのドライバがロードされないため、ローカルディスクの読み取りに失敗します。

PVSCSIドライバを差し込んでみます。

まずは、VMware Toolsのisoファイルを入手し、以下のように仮想マシンにアタッチします。

  1. シャットダウン
  2. 既存のSCSIコントローラーをLSI Logic SASからVMware 準仮想化に変更する
  3. CD/DVDドライブにデータストアISOファイルからisoファイルとして指定する
  4. 仮想マシンをパワーオン

同じようにOSの起動に失敗します。

しばらくすると、キーボード選択に遷移します。

キーボードを選択すると、トラブルシューティングの画面に遷移します。

トラブルシューティングのメニューの中でコマンドプロンプトを選択します。

コマンドプロンプトを選択すると、「Windows Recovery Environment(WinRE)」と呼ばれるリカバリー用OSのコンソールに入れます。

WinREの操作

以下のコマンドで、PVSCSIドライバの読み込みを行います。

drvload "D:\Program Files\VMware\VMware Tools\Drivers\pvscsi\Win8\amd64\pvscsi.inf"

以下のコマンドでCドライブが読み取りできるか確認します。

PVSCSIドライバがロードできていれば表示されます。

diskpart
DISKPART> list volume

展開イメージのサービスと管理 (DISM) サービス コマンドを使って、Windows イメージにドライバーを追加します。

WinREにPVSCSIドライブをロードし、Cドライブを見えるようにし、WinREからWindowsイメージにPVSCSIのドライバをインストールする流れです。

dism /image:C:\ /add-driver /driver:"D:\Program Files\VMware\VMware Tools\Drivers\pvscsi\Win8\amd64\pvscsi.inf"

ドライバの追加ができたため、WinREを終了します。

exit

PCの電源を切るを選択して、シャットダウンします。

その後、仮想マシンをパワーオンし、OSが起動できることを確認します。

Windowsのブートについて

Windowsのブートについては、以下の詳細が書かれています。

Windows のブートに関する問題のトラブルシューティング - Windows Client | Microsoft Learn

  1. プレブート: PC のファームウェアが電源オンセルフ テスト (POST) を開始し、ファームウェア設定を読み込みます。 このプロセスは、有効なシステム ディスクが検出されると終了します。 ファームウェアはマスター ブート レコード (MBR) を読み取り、Windows Boot Manager を起動します。
  2. Windows Boot Manager: Windows Boot Manager は、Windows ブート パーティションWindows ローダー (Winload.exe) を検索して起動します。
  3. Windows オペレーティング システム ローダー: Windows カーネルを起動するために必要となる重要なドライバーが読み込まれ、実行に向けてカーネルが開始します。
  4. Windows NT OS カーネル: カーネルはシステム レジストリ ハイブと、BOOT_STARTとしてマークされているその他のドライバーをメモリに読み込みます。
  5. カーネルは、システム セッションを初期化するセッション マネージャー プロセス (Smss.exe) にコントロールを渡し、BOOT_START としてマークされていないデバイスとドライバーを読み込んで起動します。

エラー画面を見比べると、kernel phaseのWindows NT OS Kernelが実行されているところで問題起きていることが分かります。

さらに、以下に詳細のトラブルシューティング方法についても書かれています。

エラー 7B またはInaccessible_Boot_Deviceのトラブルシューティングを停止する - Windows Client | Microsoft Learn

VMware Toolsを事前にインストールしていると、以下のコマンドでPVSCSIのドライバーがあることは見えますが、カーネル起動時にもともと接続していたLSI Logic SASのデバイスとドライバーを読み込もうとするが、デバイスがPVSCSIが接続されているため、ドライバーが正しく読み込まれないのかもしれません。

dism /image:C:\ /get-drivers
公開名:oem5.inf
元のファイル名:pvscsi.inf
インボックス:いいえ
クラス名:SCSIAdapter
プロバイダー名:VMware, Inc.
日付:2022/11/30
バージョン:1.3.26.0

HomelabのvSphere 7.0からvSphere 8.0へのアップグレード

以前、Homelabの構成について書いていました。なかなかHomelabのvSphere環境のアップグレードが出来ずにいましたが、vSphere8.0のUpdateも上がってきたこともありアップグレードについて書いてみようと思います。

hidemium.hatenablog.com

構成

  • vCenter 7.0U3→vCenter 8.0U2
  • ESXi 7.0U3→ESXi 8.0U2
    • USB Network Native Driver for ESXi v1.10→v1.13
  • Intel NUC NUC7i3BNH
    • Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz

vCenterアップグレード

お手軽にアップグレードするために、WindowsGUI版のインストーラーでアップグレードを行いました。

  • インストーラーを起動して、Upgradeを選択します。
  • アップグレード対象の必要なパラメーターを入力していきます。
  • deployment sizeはhomelab用なので、Tinyを選択します。
  • 入力後、Finishボタンを押すと、Upgrade - Stage 1: Deploy vCenter Serverのポップアップが表示され、VCSAのVMのデプロイが開始されます。
  • デプロイ後、Step2を選択して、Nextをクリックします。
  • Pre-upgradeのチェックが行われ、いくつか注意事項が表示されます。
  • upgrade dataを選択します。homelabなので、タスクやイベントやパフォーマンスデータは移行せず、最低限のデータだけ移行します。
  • Step2が完了すると、アップグレードが完了します。
  • vSphere Clinetにログインし、アップグレードが完了したことを確認します。

ESXiアップグレード(workload側)

workload側は、vCenterで管理されたESXiで、vCenter VMは稼働していないホストになります。Lifecycle Managerを使ってアップグレードを行ってみました。

ESXiのアップグレードを行う前に、Nested ESXiで素振りを行ってみます。

  • Nested ESXiをデプロイし、物理ESXiとは別のクラスタを用意し、そのクラスタに配置します。
  • Nested ESXi用のクラスタで、イメージの管理を行い、ESXi 8.0U2をクラスタのイメージとして設定します。
  • すべて修正をクリックし、修正の開始をクリックし、アップグレードを開始します。
  • 自動的にメンテナンスモードに切り替え、アップグレードが行われます。
  • イメージ プロファイルは、(Updated) VMware Lifecycle Manager Generated Imageと表示されるようになっていました。

Product Interoperability Matrixを確認すると、vCenter 8.0U2ではESXi 8.0U3をサポートしていないため、同じマイナーマージョンを指定しました。

USB NICを利用しているため、FlingsのUSB Network Native Driver for ESXiのドライバを追加します。

以前だと、PowerCLIを使ってイメージを作成していましたが、UIでも同様の操作ができそうなので、試してみました。

  • VMware USB NIC Fling Driver for ESXi v1.13のバンドルイメージを入手しておきます。
  • Lifecycle Managerの画面で、アクション>更新のインポートをクリックし、USB Network Native Driver for ESXiのバンドルイメージを指定します。
  • Nested ESXi用のクラスタで、イメージの編集で、コンポーネントの追加で、VMware USB NIC Fling Driverを確認し、バージョンを指定して保存します。
  • すべて修正をクリックし、修正の開始をクリックし、アップグレードを開始します。
  • 自動的にメンテナンスモードに切り替え、アップグレードが行われます。
  • アップデート後のパッケージを確認すると、以下のようなバージョンとなっていました。
名前 説明 バージョン
vmkusb USB Native Driver for VMware 0.1-18vmw.802.0.0.22380479
vmkusb-nic-fling USB Native Driver Fling for VMware ESXi 1.12-2vmw.802.0.0.67561870

物理ESXiで上記と同様にアップグレードを実施し、うまくアップグレードすることができました。

ESXiアップグレード(management側)

management側は、vCenter VMが稼働しており、homelabのため、vMotionで他のホストにvCenter VMを移行できない状態となっています。

そこで、CLIによるアップグレードを実施します。

workload側とイメージを合わせるため、workload側のLifecycle Managerからバンドルイメージをダウンロードしておきます。

  • イメージ>エクスポートをクリックし、zipを選択し、バンドルイメージをダウンロードします。
  • management側のESXiのデータストアを選択し、データストアブラウザからデータストアへバンドルイメージをアップロードします。
  • まずは、dry-runを実行して、アップグレードか可能か確認すると、以下のようなエラーが表示されます。
esxcli software sources profile list -d /vmfs/volumes/datastore1/ISO/OFFLINE_BUNDLE_52e37739-9a0d-8d0f-1525-cd1365a880be.zip 
Name                                      Vendor        Acceptance Level  Creation Time        Modification Time
----------------------------------------  ------------  ----------------  -------------------  -----------------
VMware Lifecycle Manager Generated Image  VMware, Inc.  PartnerSupported  2024-08-15T20:43:12  2024-08-15T20:43:12
esxcli software profile update -d /vmfs/volumes/datastore1/ISO/OFFLINE_BUNDLE_52e37739-9a0d-8d0f-1525-cd1365a880be.zip -p "VMware Lifecycle Mana
ger Generated Image" --dry-run
 [ProfileValidationError]
 File path of '/lib64/python3.8/unittest/loader.pyc' is claimed by multiple non-overlay VIBs: {'VMware_bootbank_esxio-base_8.0.2-0.40.23825572', 'VMware_bootbank_esx-base_8.0.2-0.40.23825572'}

VMware docsにアップグレードする際に、dry-runが動作しないという記載がありました。

dry-runでの確認はできないですが、直接CLIでESXiのアップグレードを行っていきます。

  • vCenter VMを停止します。
  • ESXiをメンテナンスモードに変更します。
  • 以下のコマンドを実行します。vLCMでのアップグレードはprofile update相当なようなので合わせておきます。
esxcli software profile update -d /vmfs/volumes/datastore1/ISO/OFFLINE_BUNDLE_52e37739-9a0d-8d0f-1525-cd1365a880be.zip -p "VMware Lifecycle Mana
ger Generated Image"
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
  • ESXiを再起動します。

vSphere Clientにログインし、ESXiのバージョンが8.0に変更されていることを確認します。

  • vCenter VMを起動します。
  • USB NICにvDSを接続している場合、ESXiのアップグレード後にアップリンクが外れることがあるため、アップリンクが外れた場合は、再度接続しておきます。

vDSアップグレード

vDSを7.0.3から8.0.0にアップグレードします。

  • vDSのアクションをクリックして、アップグレード>Distributed Switch のアップグレードをクリックします。
  • 8.0.0 - ESXi 8.0 以降を選択し、互換性に問題をないことを確認し、OKをクリックします。
  • vDSのバージョンが8.0.0に変更していることを確認ます。

まとめ

vSphere 7.0までだと、PowerCLIを使って、インストールイメージをビルドして、USBメモリにブートメディアを用意していましたが、vSphere 8.0ではほぼGUIの操作のみでアップグレードができるようになっており、homelabのアップグレードがとても楽になっていました。

  • Image BuilderやPowerCLIを使わずに、Lifecycle Managerでvibを追加してインストールイメージのビルドが可能に
  • Lifecycle ManagerでVMware USB NIC Fling Driver for ESXiの追加が可能
  • ESXi 7.0からESXi 8.0へのアップグレードの場合、esxcliでdry-runが動作せず
  • vSphere 8.0からvCenterはESXiより低いマイナーバージョンはサポート外に(vCenter 8.0U2+ESXi 8.0U3の組み合わせがサポート外に)

ESXiのCPUスケジューリングについてまとめてみた

vSphere環境を使っていて、仮想マシンのvCPUのサイジングについてベストプラクティスがいくつかありますが、そういう背景がどういったところにあるのか、ベストプラクティスから外れた場合にどうなるのか書いてみようと思います。

構成

  • vCenter 7.0 U3
  • ESXi 7.0 Update 3
  • Intel NUC NUC7i3BNH
    • Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
  • Ubuntu 22.04

よくありそうな疑問

仮想マシンのvCPUのサイジングとして、以下のものがあります。

  • 一般的なベストプラクティスとして、ハイパースレッディングが有効な環境で仮想マシンのvCPU数は物理コア数を超えないようにする

vSphereの設定として、仮想マシンのvCPUは、ハイパースレッディングが有効な場合、仮想マシンのvCPU数は論理コア数まで設定することが可能です。例えば、物理コアが24コアあった場合は、48vCPUまで設定することが可能です。

仮想マシンのvCPUを物理コアを超えた場合にどのようなことが起きるのか見ていこうと思います。

CPUスケジューリングについて

仮想マシンのvCPUがどの物理コアに割り当てされるかは、CPUスケジューラーが担っています。

複数vCPUを持った仮想マシン(SMP VM)の場合、仮想マシン内で実行されているゲスト OS とアプリケーションを、専用の物理マルチプロセッサ上で実行されているかのように見せており、ESXiが同期ケジューリングをサポートすることで実装しています。

ゲストOSは管理するすべてのプロセッサがほぼ同じ速度で実行されることを前提としています。ただし、仮想化環境では、ゲストOSによって管理されるプロセッサは、実際にはハイパーバイザーによってスケジュールされた仮想CPUであるため、複数の仮想マシン間で物理プロセッサをタイム スライスして利用しています。

Strict co-scheduling

ESX 2.xで実装されたアルゴリズムで、vCPUごとににスキューと呼ばれるずれが発生すると、さらなるスキューを防ぐために、同じ仮想マシン内のすべてのvCPUが強制的にスケジュール解除 (「同時停止」(co-stop)) されます。スキューが検出された後はすべての vCPUを同時にスケジュールする必要があるため、このアプローチは厳密な同期ケジューリングと呼ばれています。

Relaxed co-scheduling

ESX 3.xからStrict co-schedulingに代わって、Relaxed co-schedulingというアルゴリズムが実装されました.

すべてのvCPUに同期を求めるのではなく、処理を実行しているvCPUのみについてのみ同期を行う仕組みに変更されています。

ハイパースレッディングについて

ハイパースレッディングは、1つのプロセッサ上で2つスレッドからの命令を同時に実行できるようにすることで、物理的なCPU性能を向上させる技術です。

この技術により、スレッドレベルの並列処理により性能を向上させることができますが、計算リソースの総量は依然として1つの物理プロセッサが上限となります。

どの程度性能が向上するかは、処理内容によって変わり、性能が2倍になるわけではなく、1.2倍程度といわれています。

ハイパースレッディングによりアイドル リソースを有効に活用することによってパフォーマンスを向上でき、特定の重要なワークロード タイプについてスループットを向上させます。

ESXi ホストは、プロセッサ時間をインテリジェントに管理して、システム内のプロセッサ コア間で負荷が円滑に分散されるように保証します。CPU 0 と 1 はともに第 1 のコア上にあり、CPU 2 と 3 は第 2 のコア上にあるといったように、同じコア上の論理プロセッサは、連続した CPU 番号を持ちます。

仮想マシンは、同じコアの 2 つの論理プロセッサ上よりも、2 つの異なるコア上に優先的にスケジュール設定されます。

仮想マシンのvCPUを物理コアと一致した場合、物理コアを超えた場合の挙動

物理コアが2コア、ハイパースレッディングオンで4スレッドのサーバーで、仮想マシンAにはvCPU 2、仮想マシンBにはvCPU4を割り当てて、負荷ツールを実行して、挙動を確認してみます。

stressコマンド

まずは、stressコマンドですべてのvCPUに負荷をかけてみます。

2vCPUの場合、CPU使用率が高いコアはCPU番号がずれているため、2つの異なる物理コアでスケジューリングされていることが分かります。

4vCPUの場合、各コアの使用率は50%で止まっていることが分かります。

仮想マシン 物理ホストのクロック数(Mhz) 物理ホストのCPU使用率 CPU 0使用率(Core 1) CPU 1使用率(Core 1) CPU 2使用率(Core 2) CPU 3使用率(Core 2)
仮想マシンA(vCPU2) 4.7 100% 98% 2% 98% 2%
仮想マシンB(vCPU4) 4.7 100% 50% 50% 50% 50%

仮想マシンの観点で見ると、2vCPUの場合は、各コアのクロック数は物理クロック数と一致していますが、4vCPUの場合、各コアのクロック数は物理クロック数より小さい値になっていることが分かります。

4vCPUでは、仮想マシン全体のクロック数は、物理ホストのクロック数を超えて表示されていますが、実際の物理ホストのクロック数は変わらない状態となっています。

また、4vCPUでは、仮想マシンのCPU使用率は61%で止まっていることが分かります。

仮想マシン 仮想マシンのCPU使用率 仮想マシンのクロック数(Mhz) vCPU 0クロック数(Mhz) vCPU 1クロック数(Mhz) vCPU 2クロック数(Mhz) vCPU 3クロック数(Mhz)
仮想マシンA(vCPU2) 98% 4.7 2.35 - 2.35 -
仮想マシンB(vCPU4) 61% 5.9 1.47 1.47 1.47 1.47

pgbench

DBのベンチマークツールを実行して処理性能の比較をしてみようと思います。

PostgreSQLをインストールし、ベンチマークで使うでDBの作成とデータセットの初期化を行います。

$ sudo install postgresql postgresql-client postgresql-contrib
$ sudo -u postgres createdb test
$ sudo -u postgres pgbench -i -s 10 test

vCPU2とvCPU4の仮想マシンごとにベンチマークの取得を行います。

$ sudo -u postgres pgbench -c 16 -t 1000 test

各vCPUごとにベンチマークを取得してみましたが、vCPU4のほうが高い状態となりました。

これは、ハイパースレッディングにより、各コアでの性能が十分になくても、並列処理を行う場合は、パフォーマンスが出やすいことを示していそうです。

仮想マシン TPS
仮想マシンA(vCPU2) 2288
仮想マシンB(vCPU4) 3248

まとめ

試してみた内容についてまとめると以下のようなことになりそうです。

  • ハイパースレッディングが有効な環境で仮想マシンのvCPU数は物理コア数を超えると、物理ホストのCPU使用率は100%で頭打ちとなる
  • ハイパースレッディングが有効な環境で仮想マシンのvCPU数は物理コア数を超えると、並列処理を行う場合は、パフォーマンスを出しやすい
  • 仮想マシンが複数台あると、co-stopが発生しやすくなるため、物理ホスト上の仮想マシンは少なくしたほうがよいかもしれない

参考

govcを使ったvmdkイメージの移行

前回、govcを使ったフルクローンによるバックアップについて書きましたが、今回はgovcを使ってvmdkイメージの移行について試してみました。

hidemium.hatenablog.com

構成

vmdkイメージのダウンロード

今回の操作は、govcを使って仮想マシンのvmdkイメージを手元にダウンロードして、vmdkイメージをアップロードして別のVMとして作成します。

ovfファイルとしてダウンロードする方法が一番シンプルですが、動作を確認するためにあえて回り道をしつつ見ていきます。

govcのインストールと環境変数は前回と同様です。

govcでvmdkイメージをダウンロードするには以下のように実行します。

$ govc datastore.download -host hostname  -ds datastore "vm_name/vm_name-flat.vmdk" ./vm_name-flat.vmdk

ここでflat.vmdkファイルをしているのには理由があります。

データストアブラウザからだと、vmdkファイルしか見えませんが、ESXiにログインし、データストア内を見ると、flat.vmdkとvmdkファイルが存在することが分かります。

ls -lh
-rw-------    1 root     root       10.0G Jan 24 21:25 vm_name-flat.vmdk
-rw-------    1 root     root         527 Jan 24 21:27 vm_name.vmdk

xxx-flat.vmdkというファイルがダウンロードされますが、ファイルサイズがESXi内で見えるプロビジョニングサイズと同じサイズとなっていることが分かります。

flat.vmdkは、仮想マシンのデータ ディスクになります。実際のゲストOSのデータはこちらに格納されています。

vmdkは、ディスク記述子ファイルになります。関連するflat.vmdkに関する情報が記述されています。

VMDKフォーマットには複数の異なるサブフォーマットがあり、メタデータを外部記述子ファイルに保存するものと、メインデータとともに 1 つのファイルに埋め込むものがあります。

フラットイメージは事前にスペースを割り当てますが、スパースイメージは仮想マシンが書き込むにつれて増大するかたちになります。

次にgovcでflat.vmdkファイルをアップロードします。

$ govc import.vmdk -ds datastore -pool cluster-name/Resources ./vm_name-flat.vmdk new_vm_name
govc: vmdk: invalid format (must be streamOptimized)
The vmdk can be converted using one of:
  vmware-vdiskmanager -t 5 -r './vm_name-flat.vmdk' new.vmdk
  qemu-img convert -O vmdk -o subformat=streamOptimized './vm_name-flat.vmdk' new.vmdk

そうすると、streamOptimizedされたvmdkのフォーマットではないとアップロードできないと怒られます。

メッセージの通り、subformatにstreamOptimizedを指定してvmdkファイルを変換します。

$ qemu-img convert -O vmdk -o subformat=streamOptimized './vm_name-flat.vmdk' disk1.vmdk
$ ls -lh
-rw-r--r-- 1 user user 241M Jan 24 05:57 disk1.vmdk
-rw-rw-r-- 1 user user  10G Jan 23 09:31 vm_name-flat.vmdk

vmdkファイルのサイズがもともとはプロビジョニングサイズと同じサイズでしたが、変換することで実用量のサイズに変換されました。

streamOptimizedについては、こちらに記載がありました。

govcを使って、変換したvmdkファイルをアップロードします。

govcの引数には、今後作成するVM名と同じデータストア内のフォルダ名を指定しておきます。

$ govc import.vmdk -ds datastore -pool cluster-name/Resources ./disk1.vmdk new_vm_name

アップロードしたvmdkファイルを指定して、VMを作成します。

$ govc vm.create -m 2048 -c 2 -g ubuntu64Guest -host hostname -ds datastore -net network -on=false -disk="new_vm_name/disk1.vmdk" new_vm_name

vmdkをダウンロードする際に、flat.vmdkのファイルサイズでダウンロードされるため、事前にファイルサイズを小さくするには、ovfとしてダウンロードするのが一番シンプルそうではあります。

手元にvmdkファイルがあり、それを利用したい場合は、今回の方法が利用できるかもしれません。

govcを使った仮想マシンのバックアップ

前回、スナップショット技術やバックアップについて書きましたが、今回はgovcを使ってバックアップの取得について試してみました。

hidemium.hatenablog.com

構成

バックアップ

今回の操作は、govcを使って仮想マシンのクローンを用いたフルバックアップになります。

以下の手順でgovcのインストールを行います。また、合わせて環境変数を設定しておきます。

$ curl -L -o - "https://github.com/vmware/govmomi/releases/latest/download/govc_$(uname -s)_$(uname -m).tar.gz" | sudo tar -C /usr/local/bin -xvzf - govc
$ export GOVC_URL=https://<vcenter fqdn>/sdk
$ export GOVC_USERNAME="username"
$ export GOVC_PASSWORD="password"
$ export GOVC_INSECURE="1"
$ export VM="/Datacenter/vm/path/to/vm_name"
$ govc vm.info "${VM}"
Name:              vm_name
  Path:            /Datacenter/vm/path/to/vm_name
  Guest name:      Ubuntu Linux (64-bit)
  Memory:          2048MB
  CPU:             1 vCPU(s)
  Power state:     poweredOn
  Boot time:       
  IP address:   
  Host:            hostname

govcで同一のデータストアにクローンを行うには以下のように実行します。

$ govc vm.clone -vm $VM -on=false -host hostname -folder "/Datacenter/vm/path/to/folder" clone_vm_name
Cloning /Datacenter/vm/path/to/vm_name to /Datacenter/vm/path/to/folder/clone_vm_name...OK

電源オン状態でクローンをすると、スナップショットを自動で取得を行ったうえで、クローンを行ってくれます。

clone-temp-xxx という名称のスナップショットが自動で作成され、ゲストファイルシステムを静止するがオンになっており、ファイルシステムコンシステントとアプリケーションコンシステントに該当しそうです。

govcの -on オプションを false に指定することで、クローン先のVMは電源オフ状態のままとなります。

次に、govcで異なるデータストアにクローンを行うには以下のように実行します。クローン先のデータストアが異なるため、こちらはバックアップ相当になると思います。

$ govc vm.clone -vm $VM -on=false -host hostname -ds dest_datastore -folder "/Datacenter/vm/path/to/folder" clone_vm_name
Cloning /Datacenter/vm/path/to/vm_name to clone_vm_name...OK

次に、仮想マシンをダウンロードして、他の領域へ転送する想定でovaファイルをダウンロードします。

export.ovf を実行すると、ovfファイルとvmdkファイルがダウンロードされます。

$ govc export.ovf -vm $VM /path/to/folder/
Downloading vm_name-disk-0.vmdk... OK
$ ls -la /path/to/folder/vm_name
vm_name-disk-0.vmdk
vm_name.ovf

似たコマンドで datastore.download がありますが、こちらではvmdkの仮想ディスクの記述子データしかダウンロードされず、仮想ディスクの実際のデータは含まれません。

$ govc datastore.download -ds datastore folder_name/vm_name.vmdk vm_name.vmdk
$ cat vm_name.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
:

スナップショットを指定したバックアップ

以下のようにすると、指定したスナップショットからクローンを作成することができます。

$ govc snapshot.create -vm $VM snapshot_name
$ govc vm.clone -vm $VM -snapshot snapshot_name -on=false -host hostname -ds dest_datastore -folder "/Datacenter/vm/path/to/folder" clone_vm_name
Cloning /Datacenter/vm/path/to/vm_name to clone_vm_name...OK
$ govc snapshot.remove -vm $VM snapshot_name

バックアップではないですが、以下のようにするとリンククローンを作成することができます。

$ govc vm.clone -vm $VM -snapshot snapshot_name -link -on=false -host hostname -ds dest_datastore -folder "/Datacenter/vm/path/to/folder" clone_vm_name
Cloning /Datacenter/vm/path/to/vm_name to clone_vm_name...OK

リストア

フルクローンを使ったバックアップのため、リストアは指定したデータストアに対してもう一度クローンを実行するかたちで実施できます。

$ govc vm.clone -vm clone_vm_name -on=false -host hostname -ds dest_datastore -folder "/Datacenter/vm/path/to/folder" restore_vm_name
Cloning /Datacenter/vm/path/to/clone_vm_name to restore_vm_name...OK

ovfファイルからのリストアは、以下のように行います。

$ govc import.ovf -host hostname -ds datastore /path/to/folder/vm_name.ovf
Uploading vm_name-disk-0.vmdk... OK

First Class Disk (FCD)

govcコマンドを触っていると、First Class Disk (FCD) 関連のものがあることに気が付きます。

$ govc disk
  disk.create
  disk.ls
  disk.register
  disk.rm
  disk.snapshot.create
  disk.snapshot.ls
  disk.snapshot.rm
  disk.tags.attach
  disk.tags.detach

FCDのディスクを作成してみます。

$ govc disk.create -ds datastore -size 10G my-disk
Creating my-disk...OK
7584edf7-6bbd-4435-9762-609d32564d28
$ govc disk.ls -ds datastore  -l
7584edf7-6bbd-4435-9762-609d32564d28  my-disk  10.0G

試しに、スナップショットを作成してみます。

$ govc disk.snapshot.create -ds datastore 7584edf7-6bbd-4435-9762-609d32564d28 my-disk-snapshot
Snapshot 7584edf7-6bbd-4435-9762-609d32564d28...OK
d86d3465-8fa5-40c2-ac02-44ee3d15809b
$ govc disk.snapshot.ls -ds datastore 7584edf7-6bbd-4435-9762-609d32564d28
d86d3465-8fa5-40c2-ac02-44ee3d15809b  my-disk-snapshot

スナップショットからの切り戻しするサブコマンドは存在しなさそうでした。

後片付けでFCDのスナップショットとディスクを削除しておきます。

$ govc disk.snapshot.rm -ds datastore 7584edf7-6bbd-4435-9762-609d32564d28 d86d3465-8fa5-40c2-ac02-44ee3d15809b
Deleting d86d3465-8fa5-40c2-ac02-44ee3d15809b...OK
$ govc disk.rm -ds datastore 7584edf7-6bbd-4435-9762-609d32564d28
Deleting 7584edf7-6bbd-4435-9762-609d32564d28...OK

これらのコマンドの用途としては、CNSで作成した仮想ディスクのトラブルシュート周りで役に立ちそうなように見えています。

https://blogs.vmware.com/affiliates/vmware-cloud-native-storage-be-aware-of-dangling-virtual-disks-and-snapshots