ラベル VMware の投稿を表示しています。 すべての投稿を表示
ラベル VMware の投稿を表示しています。 すべての投稿を表示
2023年8月19日土曜日

TerraformでオンプレESXiに仮想マシンを作成・削除してみる

先日、TerraformをAlmaLinuxにインストールして使ってみた。

Terraformは主にAWSやAzureといったクラウドの設定をする際に利用されるツールという印象が強いが、オンプレミスのvSphere環境などでも各種設定を行うことができる

本記事では、TerraformでオンプレESXiに仮想マシンを作成・削除する手順を作る方法を記載する。

環境

環境は以下の通り。

  • ESXi : 7.0 Update 3
  • OS : AlmaLinux 9.2
  • Terraform : v1.5.2

以下URLの手順にてTerraformがインストール済みであることを前提とする。

Terraformによる仮想マシン作成手順

通常のTerraformと同じく、tfファイルを作ってterraform initterraform applyで仮想マシンを作成し、terraform destoryで仮想マシンが削除されることを確認する。

1. tfファイルを作成

TerraformでESXiを操作する場合は、「Terraform Provider for VMware vSphere」を用いる。

マニュアルに使用例は書いてあるが、vCenter Serverが存在する環境の実行例がとなるので、ESXiに対して実行する際の注意点を以下に記載する。

  • vsphere_datacenterha-datacenterを指定
  • vsphere_compute_clusterは不要。ただし、vsphere_virtual_machineのリソース指定において、resource_pool_idは必須項目なので、vsphere_resource_poolを空で作って作成しておく
  • guest_idは以下URLから[Enumerated Types]→[VirtualMachineGuestOsIdentifier]にアクセスし作成するOSの種類に合わせて正しく指定する。
  • 仮想マシン作成後にTerraformが応答待ちになってしまうことから、wait_for_guest_net_timeout = -1を設定する

上記をもとに作成したtfファイルは以下の通り。

main.tf

terraform {
  required_version = ">= 1.2.0"
}

locals {
  esxi_user              = "[ESXiのユーザ名]"
  esxi_password          = "[ESXiのユーザのパスワード]"
  esxi_server            = "[ESXiのIPアドレス]"
}

provider "vsphere" {
  user                 = local.esxi_user
  password             = local.esxi_password
  vsphere_server       = local.esxi_server
  allow_unverified_ssl = true
}

data "vsphere_datacenter" "datacenter" {
  name = "ha-datacenter"
}

data "vsphere_datastore" "datastore" {
  name          = "ssd_01"
  datacenter_id = data.vsphere_datacenter.datacenter.id
}

data "vsphere_datastore" "media" {
  name          = "nfs_01"
  datacenter_id = data.vsphere_datacenter.datacenter.id
}

data "vsphere_resource_pool" "pool" {
}

data "vsphere_network" "network" {
  name          = "Network_01"
  datacenter_id = data.vsphere_datacenter.datacenter.id
}

resource "vsphere_virtual_machine" "vm" {
  name             = "terraform-testvm"
  resource_pool_id = data.vsphere_resource_pool.pool.id
  datastore_id     = data.vsphere_datastore.datastore.id
  num_cpus         = 1
  memory           = 1024
  guest_id         = "other5xLinux64Guest"

  network_interface {
    network_id = data.vsphere_network.network.id
  }

  disk {
    label = "disk0"
    size  = 16
    thin_provisioned = true
  }

  cdrom {
    datastore_id = data.vsphere_datastore.media.id
    path = "/04_ISO/Linux/AlmaLinux/AlmaLinux-9.2-x86_64-dvd.iso"
  }

  wait_for_guest_net_timeout = -1
}

2. Terraform実行

上記tfファイルをesxi_vm_linuxディレクトリに作成し、Terraformを実行する。

# cd esxi_vm_linux
# terraform init
~(省略)~

# terraform apply 
data.vsphere_datacenter.datacenter: Reading...
data.vsphere_resource_pool.pool: Reading...
data.vsphere_datacenter.datacenter: Read complete after 0s [id=ha-datacenter]
data.vsphere_datastore.media: Reading...
data.vsphere_datastore.datastore: Reading...
data.vsphere_network.network: Reading...
data.vsphere_datastore.media: Read complete after 0s [id=192.168.1.1:/nfs]
data.vsphere_resource_pool.pool: Read complete after 0s [id=ha-root-pool]
data.vsphere_datastore.datastore: Read complete after 0s [id=63942c98-19e3f477-d004-90e2ba3d67d0]
data.vsphere_network.network: Read complete after 0s [id=HaNetwork-Network_01]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # vsphere_virtual_machine.vm will be created
  + resource "vsphere_virtual_machine" "vm" {
      + annotation                              = (known after apply)
      + boot_retry_delay                        = 10000
      + change_version                          = (known after apply)
      + cpu_limit                               = -1
      + cpu_share_count                         = (known after apply)
      + cpu_share_level                         = "normal"
      + datastore_id                            = "63942c98-19e3f477-d004-90e2ba3d67d0"
      + default_ip_address                      = (known after apply)
      + ept_rvi_mode                            = "automatic"
      + extra_config_reboot_required            = true
      + firmware                                = "bios"
      + force_power_off                         = true
      + guest_id                                = "other5xLinux64Guest"
      + guest_ip_addresses                      = (known after apply)
      + hardware_version                        = (known after apply)
      + host_system_id                          = (known after apply)
      + hv_mode                                 = "hvAuto"
      + id                                      = (known after apply)
      + ide_controller_count                    = 2
      + imported                                = (known after apply)
      + latency_sensitivity                     = "normal"
      + memory                                  = 1024
      + memory_limit                            = -1
      + memory_share_count                      = (known after apply)
      + memory_share_level                      = "normal"
      + migrate_wait_timeout                    = 30
      + moid                                    = (known after apply)
      + name                                    = "terraform-testvm"
      + num_cores_per_socket                    = 1
      + num_cpus                                = 1
      + power_state                             = (known after apply)
      + poweron_timeout                         = 300
      + reboot_required                         = (known after apply)
      + resource_pool_id                        = "ha-root-pool"
      + run_tools_scripts_after_power_on        = true
      + run_tools_scripts_after_resume          = true
      + run_tools_scripts_before_guest_shutdown = true
      + run_tools_scripts_before_guest_standby  = true
      + sata_controller_count                   = 0
      + scsi_bus_sharing                        = "noSharing"
      + scsi_controller_count                   = 1
      + scsi_type                               = "pvscsi"
      + shutdown_wait_timeout                   = 3
      + storage_policy_id                       = (known after apply)
      + swap_placement_policy                   = "inherit"
      + tools_upgrade_policy                    = "manual"
      + uuid                                    = (known after apply)
      + vapp_transport                          = (known after apply)
      + vmware_tools_status                     = (known after apply)
      + vmx_path                                = (known after apply)
      + wait_for_guest_ip_timeout               = 0
      + wait_for_guest_net_routable             = true
      + wait_for_guest_net_timeout              = -1

      + cdrom {
          + datastore_id   = "192.168.1.1:/nfs"
          + device_address = (known after apply)
          + key            = (known after apply)
          + path           = "/04_ISO/Linux/AlmaLinux/AlmaLinux-9.2-x86_64-dvd.iso"
        }

      + disk {
          + attach            = false
          + controller_type   = "scsi"
          + datastore_id      = "<computed>"
          + device_address    = (known after apply)
          + disk_mode         = "persistent"
          + disk_sharing      = "sharingNone"
          + eagerly_scrub     = false
          + io_limit          = -1
          + io_reservation    = 0
          + io_share_count    = 0
          + io_share_level    = "normal"
          + keep_on_remove    = false
          + key               = 0
          + label             = "disk0"
          + path              = (known after apply)
          + size              = 16
          + storage_policy_id = (known after apply)
          + thin_provisioned  = true
          + unit_number       = 0
          + uuid              = (known after apply)
          + write_through     = false
        }

      + network_interface {
          + adapter_type          = "vmxnet3"
          + bandwidth_limit       = -1
          + bandwidth_reservation = 0
          + bandwidth_share_count = (known after apply)
          + bandwidth_share_level = "normal"
          + device_address        = (known after apply)
          + key                   = (known after apply)
          + mac_address           = (known after apply)
          + network_id            = "HaNetwork-Network_01"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

vsphere_virtual_machine.vm: Creating...
vsphere_virtual_machine.vm: Creation complete after 1s [id=564de646-7f10-7d49-33d3-7c55f22ef581]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

作成した結果をVMware Host Clientにて確認してみると、問題なくterraform-testvmの仮想マシンが作成され、起動まで実行されていることがわかる。

「設定の編集」を確認すると、USBコントローラなどがない、必要最低限の構成で仮想マシンが作成されていた。

Terraformによる仮想マシン削除手順

最後に作成した仮想マシンを削除してみよう。仮想マシンの削除はterraform destroyをすればよい。

# terraform destroy 
data.vsphere_resource_pool.pool: Reading...
data.vsphere_datacenter.datacenter: Reading...
data.vsphere_datacenter.datacenter: Read complete after 0s [id=ha-datacenter]
data.vsphere_network.network: Reading...
data.vsphere_datastore.media: Reading...
data.vsphere_datastore.datastore: Reading...
data.vsphere_datastore.datastore: Read complete after 0s [id=63942c98-19e3f477-d004-90e2ba3d67d0]
data.vsphere_datastore.media: Read complete after 0s [id=192.168.1.1:/nfs]
data.vsphere_resource_pool.pool: Read complete after 0s [id=ha-root-pool]
data.vsphere_network.network: Read complete after 0s [id=HaNetwork-Network_01]
vsphere_virtual_machine.vm: Refreshing state... [id=564de646-7f10-7d49-33d3-7c55f22ef581]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:

  # vsphere_virtual_machine.vm will be destroyed
  - resource "vsphere_virtual_machine" "vm" {
      - boot_delay                              = 0 -> null
      - boot_retry_delay                        = 10000 -> null
      - boot_retry_enabled                      = false -> null
      - change_version                          = "2023-08-11T09:27:30.121451Z" -> null
      - cpu_hot_add_enabled                     = false -> null
      - cpu_hot_remove_enabled                  = false -> null
      - cpu_limit                               = -1 -> null
      - cpu_performance_counters_enabled        = false -> null
      - cpu_reservation                         = 0 -> null
      - cpu_share_count                         = 1000 -> null
      - cpu_share_level                         = "normal" -> null
      - datastore_id                            = "63942c98-19e3f477-d004-90e2ba3d67d0" -> null
      - efi_secure_boot_enabled                 = false -> null
      - enable_disk_uuid                        = false -> null
      - enable_logging                          = false -> null
      - ept_rvi_mode                            = "automatic" -> null
      - extra_config                            = {} -> null
      - extra_config_reboot_required            = true -> null
      - firmware                                = "bios" -> null
      - force_power_off                         = true -> null
      - guest_id                                = "other5xLinux64Guest" -> null
      - guest_ip_addresses                      = [] -> null
      - hardware_version                        = 19 -> null
      - host_system_id                          = "ha-host" -> null
      - hv_mode                                 = "hvAuto" -> null
      - id                                      = "564de646-7f10-7d49-33d3-7c55f22ef581" -> null
      - ide_controller_count                    = 2 -> null
      - latency_sensitivity                     = "normal" -> null
      - memory                                  = 1024 -> null
      - memory_hot_add_enabled                  = false -> null
      - memory_limit                            = -1 -> null
      - memory_reservation                      = 0 -> null
      - memory_share_count                      = 10240 -> null
      - memory_share_level                      = "normal" -> null
      - migrate_wait_timeout                    = 30 -> null
      - moid                                    = "59" -> null
      - name                                    = "terraform-testvm" -> null
      - nested_hv_enabled                       = false -> null
      - num_cores_per_socket                    = 1 -> null
      - num_cpus                                = 1 -> null
      - pci_device_id                           = [] -> null
      - power_state                             = "on" -> null
      - poweron_timeout                         = 300 -> null
      - reboot_required                         = false -> null
      - resource_pool_id                        = "ha-root-pool" -> null
      - run_tools_scripts_after_power_on        = true -> null
      - run_tools_scripts_after_resume          = true -> null
      - run_tools_scripts_before_guest_reboot   = false -> null
      - run_tools_scripts_before_guest_shutdown = true -> null
      - run_tools_scripts_before_guest_standby  = true -> null
      - sata_controller_count                   = 0 -> null
      - scsi_bus_sharing                        = "noSharing" -> null
      - scsi_controller_count                   = 1 -> null
      - scsi_type                               = "pvscsi" -> null
      - shutdown_wait_timeout                   = 3 -> null
      - swap_placement_policy                   = "inherit" -> null
      - sync_time_with_host                     = false -> null
      - sync_time_with_host_periodically        = false -> null
      - tools_upgrade_policy                    = "manual" -> null
      - uuid                                    = "564de646-7f10-7d49-33d3-7c55f22ef581" -> null
      - vapp_transport                          = [] -> null
      - vbs_enabled                             = false -> null
      - vmware_tools_status                     = "guestToolsNotRunning" -> null
      - vmx_path                                = "terraform-testvm/terraform-testvm.vmx" -> null
      - vvtd_enabled                            = false -> null
      - wait_for_guest_ip_timeout               = 0 -> null
      - wait_for_guest_net_routable             = true -> null
      - wait_for_guest_net_timeout              = -1 -> null

      - cdrom {
          - client_device  = false -> null
          - datastore_id   = "192.168.1.1:/nfs" -> null
          - device_address = "ide:0:0" -> null
          - key            = 3000 -> null
          - path           = "04_ISO/Linux/AlmaLinux/AlmaLinux-9.2-x86_64-dvd.iso" -> null
        }

      - disk {
          - attach           = false -> null
          - controller_type  = "scsi" -> null
          - datastore_id     = "63942c98-19e3f477-d004-90e2ba3d67d0" -> null
          - device_address   = "scsi:0:0" -> null
          - disk_mode        = "persistent" -> null
          - disk_sharing     = "sharingNone" -> null
          - eagerly_scrub    = false -> null
          - io_limit         = -1 -> null
          - io_reservation   = 0 -> null
          - io_share_count   = 1000 -> null
          - io_share_level   = "normal" -> null
          - keep_on_remove   = false -> null
          - key              = 2000 -> null
          - label            = "disk0" -> null
          - path             = "terraform-testvm/terraform-testvm.vmdk" -> null
          - size             = 16 -> null
          - thin_provisioned = true -> null
          - unit_number      = 0 -> null
          - uuid             = "6000C29e-8a40-b94b-d566-a61c53225832" -> null
          - write_through    = false -> null
        }

      - network_interface {
          - adapter_type          = "vmxnet3" -> null
          - bandwidth_limit       = -1 -> null
          - bandwidth_reservation = 0 -> null
          - bandwidth_share_count = 50 -> null
          - bandwidth_share_level = "normal" -> null
          - device_address        = "pci:0:7" -> null
          - key                   = 4000 -> null
          - mac_address           = "00:0c:29:2e:f5:81" -> null
          - network_id            = "HaNetwork-Network_01" -> null
          - use_static_mac        = false -> null
        }
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

vsphere_virtual_machine.vm: Destroying... [id=564de646-7f10-7d49-33d3-7c55f22ef581]
vsphere_virtual_machine.vm: Destruction complete after 1s

Destroy complete! Resources: 1 destroyed.

ESXiの「最近のタスク」においても、仮想マシンの電源をOFFしてから削除処理が実行されていることがわかる。

以上で、TerraformでオンプレESXiに仮想マシンを作成・削除する手順は完了となる。

2023年1月28日土曜日

【PowerCLI】仮想マシンハードウェアをバージョンアップする方法

ESXiをバージョンアップした際などに、仮想マシンのサマリ画面にて「この仮想マシンに設定されたゲストは、現在実行中のゲストと一致しません」といった警告メッセージが表示される場合がある。

これは、バージョンアップ前のESXiでは対応していなかったOS種別が、新しいESXiの仮想マシンハードウェアで対応したことの影響となる。

特に仮想マシンの動作に影響を及ぼすものではないが、警告メッセージを消したい場合は、ハードウェアバージョンアップを行ったのち、仮想マシンのゲストOS設定を修正する必要がある。ただし、仮想マシンのハードウェアバージョンアップはVMware Host Clientでは行うことはできない。

そこで本記事では、PowerCLIを用いて仮想マシンハードウェアをバージョンアップをする方法を記載する。

環境

本環境を実施した環境は以下の通り。vCenter Serverは構築していないため、ESXiに対してPowerCLIからコマンド実行を行う。

  • ESXi : 7.0 Update 3 (20328353)
  • PowerCLI : 12.7.0 build 20091289
  • 作業対象仮想マシン名 : vyos
    • 仮想マシンハードウェア(前) : vmx-14
    • 仮想マシンハードウェア(後) : vmx-19

仮想マシンハードウェアのバージョンアップ手順

1. 仮想マシンを停止

本作業の前提として仮想マシンの停止が必要となるため、あらかじめ作業対象の仮想マシンを停止しておく。

2. バージョンアップ前確認

バージョンアップ前に仮想マシンハードウェアのバージョン確認を行う。HardwareVersionが仮想マシンハードウェアを表しており、バージョンアップ前はvmx-14であることがわかる。これはESXi 6.7が対応しているバージョンとなる。

PS> Get-VM vyos| fl *

Name                    : vyos
PowerState              : PoweredOff

~(中略)~

Version                 : v14
HardwareVersion         : vmx-14 ★
PersistentId            : 528c62f8-48d4-4ccc-0a7d-a05c02f07afa
GuestId                 : debian10_64Guest

~(以下略)~

2. バージョンアップ前スナップショット取得

バージョンアップ前に念のため仮想マシンのスナップショットを取得しておく。

PS> Get-VM vyos| New-Snapshot -Name "Before hardware version upgrade"

Name                 Description                    PowerState
----                 -----------                    ----------
Before hardware v...                                PoweredOff

3. 仮想マシンハードウェアをバージョンアップ

バージョンアップは以下コマンドで実行する。今回はESXi 7.0 Update 2以降で対応しているvmx-19にバージョンアップを行った。コマンドを実行すれば処理はすぐに完了する。

PS> (Get-VM vyos).ExtensionData.UpgradeVM('vmx-19')

なお、以前のPowerCLIではSet-VMコマンドレットでバージョンアップできたようだが、PowerCLI 12.7では以下の通り実行に失敗するので注意。

PS> Get-VM vyos| Set-VM -Version "v19" -Confirm:$false
Set-VM : パラメーター 'Version' をバインドできません。値 "v19" を型 "VMware.VimAutomation.ViCore.Types.V1.VM.VMVersion"
 に変換できません。エラー: "識別子名 v19 は有効な列挙子名に一致しません。次のいずれかの列挙子名を指定して再試行してくだ
さい:
Unknown, v4, v7, v8, v9, v10, v11, v12, v13, v14"
発生場所 行:1 文字:36
+ Get-VM vyos| Set-VM -Version "v19" -Confirm:$false
+                                    ~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Set-VM]、ParameterBindingException
    + FullyQualifiedErrorId : CannotConvertArgumentNoMessage,VMware.VimAutomation.ViCore.Cmdlets.Commands.SetVM

4. バージョンアップ後確認

バージョンアップ後の仮想マシンの状態確認を行う。HardwareVersionvmx-19になっていれば問題ない。

PS> Get-VM vyos| fl *


警告: The 'Version' property of VirtualMachine type is deprecated. Use the 'HardwareVersion' property instead.
Name                    : vyos
PowerState              : PoweredOff

~(中略)~

Version                 : Unknown
HardwareVersion         : vmx-19 ★
PersistentId            : 528c62f8-48d4-4ccc-0a7d-a05c02f07afa
GuestId                 : debian10_64Guest

~(以下略)~

5. ゲストOS設定変更&仮想マシン起動

VMware Host Clientにログインし、[対象の仮想マシン]→[設定の編集]→[仮想マシン オプション]→[一般オプション]→[ゲストOSのバージョン]から、警告メッセージに表示されていたOSを選択する。なお、仮想マシンハードウェアのバージョンをバージョンアップしていない場合は、そもそも選択肢に新しいOSは表示されないため注意しよう。

その後、仮想マシンを起動することで、警告メッセージが消えるはずだ。

6. バージョンアップ後スナップショット削除

その後の仮想マシンが問題なく起動したようであれば、作業前のバックアップを削除する。

PS> Get-VM vyos| Get-Snapshot -Name "Before hardware version upgrade" | Remove-Snapshot -Confirm:$false

以上で、PowerCLIを用いて仮想マシンハードウェアをバージョンアップをする方法の説明は終了となる。

参考

2022年10月15日土曜日

ESXi 7.0・ESXi 8.0のOS領域を最小サイズでインストールする

ESXi 7.0やESXi 8.0では、ESXi 6.7の頃と比較してOS領域のパーティションが大幅に設計変更が加わっている。先に結論を言うと、ESXi 6.7以前は数GB程度と非常に少ない容量でOSインストールをすることができたが、ESXi 7.0(ESXi 8.0)では最大で128GBがOSインストール領域として使用される

以下に、ESXi 6.7とESXi 7.0(ESXi 8.0)のdfコマンドの結果を比較した結果を記載する。

▼ESXi 6.7
ESXi 6.7では、OS領域であるvfatの領域が4つが作成され、残りの容量はVMFS-6のデータストアが作成されている。

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      32.5G   1.4G     31.1G   4% /vmfs/volumes/datastore1
vfat       249.7M 147.6M    102.1M  59% /vmfs/volumes/f471577b-dca3afaf-29c3-0d637cde3004
vfat       285.8M 195.8M     90.0M  68% /vmfs/volumes/60022d77-6ee455cf-0106-000c29369e16
vfat       249.7M   4.0K    249.7M   0% /vmfs/volumes/eb87dc73-7f38d4c9-e1f8-0b2e37658546
vfat         4.0G   4.2M      4.0G   0% /vmfs/volumes/60022d81-569c280c-e4f2-000c29369e16

▼ESXi 7.0(ESXi 8.0)
ESXi 6.7では、OS領域であるvfatの領域が2つが「BOOTBANK1」と「BOOTBANK2」というボリューム名で作成されている。残りの領域は「OSDATA」というボリュームが作成されており、VMFSのデータ領域として利用できる領域は存在しない。

[root@localhost:~] df -h
Filesystem  Size   Used Available Use% Mounted on
VFFS       31.8G   2.8G     29.0G   9% /vmfs/volumes/OSDATA-60039d1b-e99807cf-372a-000c29ff2470
vfat        4.0G 169.3M      3.8G   4% /vmfs/volumes/BOOTBANK1
vfat        4.0G  64.0K      4.0G   0% /vmfs/volumes/BOOTBANK2

上記のようにESXi 7.0(ESXi 8.0)では、インストール対象のディスクサイズが128GB未満の場合は全領域が「OSDATA]というOS領域として確保され、仮想マシン用のデータストアとしては使用できない。検証用途でESXi 7.0を使用する場合、多くの容量がOS領域に使用されるため非常に効率が悪い。

そこで、ESXi 7.0(ESXi 8.0)のインストール時もOSのインストールサイズを縮小し、残りのディスク容量をデータストアとして使用できる手順を確認した。

手順としては以下2つの方法で対処できる。最も容量を減らしたい場合は、2番目のESXi 6.7からのアップグレード手順がおすすめとなる。

  1. ESXi 7.0(ESXi 8.0)のインストーラのブートオプションにautoPartitionOSDataSize=8192を指定
  2. ESXi 6.7インストール後、ESXi 7.0(ESXi 8.0)にアップグレード

以下に、それぞれの手順を記載する。なお、ESXi 6.7からESXi 7.0(ESXi 8.0)にアップグレードする場合は、アップグレードパスをVMwareのサイトで確認しておこう。

環境

環境は以下の通り。本記事の手順は、ESXi 7.0とESXi 8.0両方で使用できるが、手順説明はESXi 7.0を用いて実施する。
  • ESXi 7.0 Update 1c及びESXi 8.0
  • Nested ESXi環境
  • OSインストールディスク容量 : 40GB

ESXi 7.0のインストーラのブートオプションにautoPartitionOSDataSize=8192を指定

1. ESXiのインストーラ起動時に「Shift+O」を押す

「Shift+O」を押すことで、ブートオプションを追加できるようになる。画面表示から5秒以内に押す必要があるので注意しよう。

2. OSData領域のサイズを指定

初めからcdromBoot runweaselと入力されているので、続けて以下のようにautoPartitionOSDataSize=8192のパラメータを追加し、Enterを押下する。

cdromBoot runweasel autoPartitionOSDataSize=8192

3. 通常手順にてインストールを実施

通常の手順にてESXiをインストールする。以前別記事でインストール手順は確認しているので、詳細はそちらを参照いただきたい。

4. インストール後のパーティションの確認

インストール後のディスクパーティションを確認してみると、OSDATA領域は約8GBの容量に抑えられたことにより、残りの容量がVMFS-6のデータストアとして作成されていることがわかる。ただし、40GBのディスクのうち、データストアの容量は23.8GBのみとなった。

[root@localhost:~] df -h
Filesystem  Size   Used Available Use% Mounted on
VMFS-6     23.8G   1.4G     22.3G   6% /vmfs/volumes/datastore1
VFFS        7.8G   2.8G      5.0G  36% /vmfs/volumes/OSDATA-600399b1-ae861d06-cb7b-000c29ff2470
vfat        4.0G 169.4M      3.8G   4% /vmfs/volumes/BOOTBANK1
vfat        4.0G  64.0K      4.0G   0% /vmfs/volumes/BOOTBANK2

ESXi 6.7インストール後、ESXi 7.0(ESXi 8.0)にアップグレード

1. ESXi 6.7を通常インストール

ESXi 6.7を通常インストールする。特別な手順は不要となる。この時点では、パーティションは以下の通りとなり、40GBのうち32.5GBがVMFS-6のデータストアとして作成されている。

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      32.5G   1.4G     31.1G   4% /vmfs/volumes/datastore1
vfat       249.7M 147.6M    102.1M  59% /vmfs/volumes/f471577b-dca3afaf-29c3-0d637cde3004
vfat       285.8M 195.8M     90.0M  68% /vmfs/volumes/60022d77-6ee455cf-0106-000c29369e16
vfat       249.7M   4.0K    249.7M   0% /vmfs/volumes/eb87dc73-7f38d4c9-e1f8-0b2e37658546
vfat         4.0G   4.2M      4.0G   0% /vmfs/volumes/60022d81-569c280c-e4f2-000c29369e16

2. ESXi 6.7をシャットダウン

ESXi 7.0にアップグレードするため、ESXi 6.7を一度シャットダウンする。

3. ESXi 7.0(ESXi 8.0)のインストーラにてブート

ESXi 7.0(ESXi 8.0)のインストールISOイメージを使って、ESXi 7.0(ESXi 8.0)のインストーラをブートする。

Nested ESXiの環境は、仮想ディスクのブート順位が高いため、仮想マシンの「設定の編集」→「仮想マシン オプション」→「起動オプション」→「強制的にBIOSセットアップ」にチェックを入れたのち、仮想マシンを起動させる。

起動にBIOSのBoot Managerが表示されるので、「EFI VMware Virtual SATA CDROM Drive (0.0)」を選択し、ESXi 7.0のISOイメージから起動を実施する。

4. ESXi 7.0(ESXi 8.0)にアップグレード

ESXiをアップグレードするが、手順としては通常インストールとほぼ同一となる。唯一の変更点は、インストールディスク選択時に「ESXi and VMFS found」の画面が表示されるので、必ず「Upgrade ESXi, preserve VMFS datastore」を選択すること。

5. インストール後のパーティションの確認

インストール後のディスクパーティションを確認してみると、OS領域だけでなく、VMFS-6のデータストアも作成されていることがわかる。ESXi 6.7のデータストアは維持されるため、ESXi 7.0(ESXi 8.0)となっても、データストアの容量は32.5GBの容量から変化しない。

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      32.5G   1.4G     31.1G   4% /vmfs/volumes/datastore1
VFFS         6.2G   2.7G      3.5G  44% /vmfs/volumes/OSDATA-600248ad-7bcf04bf-134c-000c29369e16
vfat       499.7M 166.1M    333.6M  33% /vmfs/volumes/BOOTBANK2
vfat       499.7M   8.0K    499.7M   0% /vmfs/volumes/BOOTBANK1

参考

更新履歴

  • 2021/3/30 新規作成
  • 2022/10/15 ESXi 8.0の記述を追記
2022年10月8日土曜日

ESXi 6.7 Update 3をESXi 7.0 Update 3にバージョンアップする手順

ESXi 6.7は2022/10/15にGENERAL SUPPORTが終了となる(TECHNICAL GUIDANCEはその1年後)。自宅では、2018年から長らくESXi 6.7を使って稼働させてきた。

しかし、上記サポート終了を受け、とうとう自宅サーバをESXi 6.7 Update 3からESXi 7.0 Update 3にバージョンアップした。バージョンアップ自体は問題なく実施できたが、他にも同様にバージョンアップをする場合に参考になるかもしれないので、本記事では、私が実施したESXi 6.7 Update 3からESXi 7.0 Update 3にバージョンアップする手順を記載する。

環境

今回の環境は以下の通り。

  • バージョンアップ前:ESXi 6.7 Update 3
  • バージョンアップ後:ESXi 7.0 Update 3

ESXi 6.7に追加で個別にVIBをインストールしていたりすると、バージョンアップ時にエラーとなり失敗するケースがある。例えば、ESXi 7.0から利用できないRealtek製NICのドライバなどがインストールされているとエラーとなる可能性がある。

そこで今回は直接バージョンアップするのではなく、一度ESXi 6.7をクリーンインストールしたのち、ESXi 7.0にバージョンアップする手順としている。またこの方法を用いると、ESXi 7.0のインストール領域が最小限に抑えることもできる。詳細は以下記事を参照いただきたい。

ESXi 6.7 Update 3からESXi 7.0 Update 3へのバージョンアップ手順

1. (Realtek製NICを使用している場合) Intel NICなどにNIC変更を実施

ESXi 6.7ではRealtek製NICであっても、有志が作成したドライバを導入することでESXiのNICとして認識させることができた。しかし、ESXi 7.0ではRealtek製NICをサポートしておらず使用することができない

そのため、既存環境でRealtek製NICを使用している場合は、新たにPCIカードのIntel製NICに変更するか、USB NICなどに変更する必要がある。

USB NICを使用する場合は、使用できるチップセットや事前に必要となるVIBファイルなどがあるため、詳細は以下記事を参照いただきたい。

ちなみに、私の自宅サーバはIntel製NICが4ポートあり空きポートが存在いたことから、仮想スイッチの物理NICを変更することで対処した。

2. PowerCLIで設定値保存

ESXiクリーンインストール前に、設定値を保存しておく。今回は突貫ではあるが以下のようなPowerCLIの簡単なコマンド一覧を使って設定値の保存を行った。

# Hardware
Get-VMHostHardware | fl *
Get-VMHostPciDevice | ft -AutoSize -Wrap

# Host
Get-VMHost | fl *
Get-VMHostAccount | ft -AutoSize -Wrap
Get-VMHostAdvancedConfiguration | ft -AutoSize -Wrap
Get-VMHostService | ft -AutoSize -Wrap

(Get-VMHost | Get-EsxCli).system.snmp.get()

# Network
Get-VMHostNetworkAdapter | ft -AutoSize -Wrap
Get-VMHostNetwork | fl *
Get-VMHostNetworkStack | fl *
Get-VMHostFirewallException | ft -AutoSize -Wrap
Get-VMHostRoute | ft -AutoSize -Wrap

Get-VirtualNetwork | ft -AutoSize -Wrap
Get-VirtualPortGroup | ft -AutoSize -Wrap
Get-VirtualSwitch | ft -AutoSize -Wrap
Get-VirtualSwitch | Get-SecurityPolicy | ft -AutoSize -Wrap

# Disk & Datastore
Get-VMHostDisk | fl *
Get-VMHostDiskPartition | ft -AutoSize -Wrap
Get-VMHostHba | fl *
Get-VMHostStorage | fl *

Get-Datastore | ft -AutoSize -Wrap

# VM
Get-VM

3. ESXi 6.7をクリーンインストール

ESXi 6.7 Update 3をクリーンインストールする。手順自体はインストールISOイメージをマウントしてインストールするだけなので詳細は割愛するが、途中確認される「ESXi and VMFS Found」の画面では、必ず「Install ESXi, preserve VMFS datastore」を選択すること。ここを間違えると、データストアにある仮想マシンが消失するので注意する。

インストールできたら、最低限ネットワークとVMkernelポートの設定を行い、データストアが問題なく認識していることを確認しておこう。

4. ESXi 7.0にバージョンアップ

続いて、ESXi 7.0 Update 3にバージョンアップする。手順自体はインストールISOイメージをマウントしてインストールするだけなので詳細は割愛するが、途中確認される「ESXi and VMFS Found」の画面では、必ず「Upgrade ESXi, preserve VMFS datastore」を選択すること。ここを間違えると、データストアにある仮想マシンが消失するので注意する。

インストールできたら、最低限ネットワークとVMkernelポートの設定を行い、データストアが問題なく認識していることを確認しておこう。

5. 各種設定を実施

後は、もともとのESXiに設定していた各種設定を反映させよう。私の環境の場合は以下設定の反映が必要だった。

  • VMkernel設定
  • 仮想スイッチ設定
  • ポートグループ設定
  • NTP設定
  • ユーザ及びロール設定
  • SNMP Trap設定
  • ESXi起動時の仮想マシンの自動起動設定

以上で、ESXi 6.7 Update 3からESXi 7.0 Update 3にバージョンアップする手順は完了となる。本手順でバージョンアップした自宅サーバは、バージョンアップ後、特に問題なく稼働している。


2022年8月27日土曜日

AnsibleでESXi上に仮想マシンを構築する

これまでAnsibleで、LinuxやWindows Serverの初期構築と単体テストを実施してきた。今回は、Ansibleを使ってESXi上に仮想マシンを構築するPlaybookを作ってみたので紹介する。なお、私の環境の問題でESXiを用いているが、少し修正すればvCenter Server経由でも実行することができるだろう。

今までのAnsible関連記事

環境

コントロールノードのLinuxのOSは、AlmaLinuxにて構築している。実行対象のESXiは、ESXi 6.7となる。なお、ESXiの無償ライセンスではPlaybookを実行できないため注意する。

  • コントロールノード
    • OS : AlmaLinux 8.5
    • Ansible : ansible [core 2.13.1]
  • Ansible実行対象サーバ
    • OS : ESXi 6.7

Ansibleコントロールノードでの設定

1. pyVmomiをインストール

PythonでESXiやvCenter Serverの管理をできるようpyVmomiをインストールする。これはpipを使ってインストールすればよい。

# pip install pyvmomi

2. vSphere Automation Python SDKをインストール

pyVmomiとは別に、vSphere Automation Python SDKもインストールを行う。こちらは、gitを使う必要があるので、gitをインストールしたのち、pipにてインストールを行う。

# dnf install git -y
# pip install --upgrade git+https://github.com/vmware/vsphere-automation-sdk-python.git
Collecting git+https://github.com/vmware/vsphere-automation-sdk-python.git
  Cloning https://github.com/vmware/vsphere-automation-sdk-python.git to /tmp/pip-req-build-qjay0ffh
  Running command git clone --filter=blob:none --quiet https://github.com/vmware/vsphere-automation-sdk-python.git /tmp/pip-req-build-qjay0ffh
  Resolved https://github.com/vmware/vsphere-automation-sdk-python.git to commit 4bad74ad6be25a41fef7f0bfaa13a17b25039d25
  Preparing metadata (setup.py) ... done

~(中略)~

Installing collected packages: lxml, pyOpenSSL, vapi-runtime, vapi-common-client, vapi-client-bindings, vmc-draas-client-bindings, vmc-client-bindings, nsx-vmc-policy-python-sdk, nsx-vmc-aws-integration-python-sdk, nsx-python-sdk, nsx-policy-python-sdk, vSphere-Automation-SDK
  Running setup.py install for vSphere-Automation-SDK ... done
Successfully installed lxml-4.9.1 nsx-policy-python-sdk-3.1.5.0.0 nsx-python-sdk-3.1.5.0.0 nsx-vmc-aws-integration-python-sdk-3.1.5.0.0 nsx-vmc-policy-python-sdk-3.1.5.0.0 pyOpenSSL-22.0.0 vSphere-Automation-SDK-1.78.0 vapi-client-bindings-3.8.0 vapi-common-client-2.34.0 vapi-runtime-2.34.0 vmc-client-bindings-1.60.0 vmc-draas-client-bindings-1.19.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv

3. 動作確認

これだけでESXiやvCenter Serverに対してAnsible実行ができるようになる。テスト用として、ESXiの情報を取得するPlaybookを作成したので、実際にPlaybookを実行して、問題なく実行できることを確認してみよう。

インベントリーファイル

hostsというファイル名で以下の通り1台のESXiを記載したインベントリーファイルを作成した。

[vmware_servers]
esxi01 ansible_host=192.168.1.1

Playbook

test_esxi_connection.ymlというファイル名で以下の通りPlaybookを作成した。ユーザ名、パスワードなどの変数は、環境に合わせて修正すること。

---
- name: Test esxi connection
  gather_facts: false
  hosts: vmware_servers

  vars:
    ansible_connection: local
    ansible_python_interpreter: /usr/bin/python3.8
    esxi_username: root
    esxi_password: !vault |
      $ANSIBLE_VAULT;1.1;AES256
      37316332366436396537613265366334323663646463306163353665323836636362323334313763
      ~(中略)~
      3730

  tasks:
    - name: Get vmware host facts
      community.vmware.vmware_host_facts:
        hostname: "{{ inventory_hostname }}"
        username: "{{ esxi_username }}"
        password: "{{ esxi_password }}"
        validate_certs: false
      register: result

    - name: Show vmware host facts
      ansible.builtin.debug:
        msg: "{{ result }}"

実行結果

ok=2となることが確認できればOKとなる。

# ansible-playbook -i hosts test_esxi_connection.yml 

PLAY [Create vmware vm] ********************************************************************************************

TASK [Get vmware host facts] ***************************************************************************************
ok: [esxi01]

TASK [Show vmware host facts] **************************************************************************************
ok: [esxi01] => {
    "msg": {
        "ansible_facts": {
            "ansible_all_ipv4_addresses": [
                "192.168.1.1",
                "192.168.2.1"
            ],
            "ansible_bios_date": "2018-07-12T00:00:00+00:00",
            "ansible_bios_version": "P3.00",
            "ansible_datastore": [
                {
                    "free": "326.41 GB",
                    "name": "Datastore_01",
                    "total": "458.25 GB"
                },
                {
                    "free": "641.69 GB",
                    "name": "Datastore_02",
                    "total": "931.25 GB"
                },
                {
                    "free": "584.54 GB",
                    "name": "nfs_01",
                    "total": "1.94 TB"
                }
            ],
            "ansible_distribution": "VMware ESXi",
            "ansible_distribution_build": "18828794",
            "ansible_distribution_version": "6.7.0",
            "ansible_hostname": "esxi01",
            "ansible_in_maintenance_mode": false,
            "ansible_interfaces": [
                "vmk0",
                "vmk1"
            ],
            "ansible_memfree_mb": 6108,
            "ansible_memtotal_mb": 32420,
            "ansible_os_type": "vmnix-x86",
            "ansible_processor": "Intel(R) Core(TM) i5-8400 CPU @ 2.80GHz",
            "ansible_processor_cores": 6,
            "ansible_processor_count": 1,
            "ansible_processor_vcpus": 6,
            "ansible_product_name": "To Be Filled By O.E.M.",
            "ansible_product_serial": "To Be Filled By O.E.M.",
            "ansible_system_vendor": "To Be Filled By O.E.M.",
            "ansible_uptime": 13418913,
            "ansible_uuid": "8cc28570-1edb-0000-0000-000000000000",
            "ansible_vmk0": {
                "device": "vmk0",
                "ipv4": {
                    "address": "192.168.1.1",
                    "netmask": "255.255.255.0"
                },
                "macaddress": "70:85:c2:8c:xx:xx",
                "mtu": 1500
            },
            "ansible_vmk1": {
                "device": "vmk1",
                "ipv4": {
                    "address": "192.168.2.1",
                    "netmask": "255.255.255.0"
                },
                "macaddress": "00:50:56:64:xx:xx",
                "mtu": 1500
            },
            "cluster": null,
            "host_date_time": {
                "date": "2022-08-21",
                "day": "21",
                "epoch": "1661038759",
                "hour": "08",
                "iso8601": "2022-08-21T08:39:19Z",
                "iso8601_basic": "20220821T083919210083",
                "iso8601_basic_short": "20220821T083919",
                "iso8601_micro": "2022-08-21T08:39:19.210083Z",
                "minute": "39",
                "month": "08",
                "second": "19",
                "time": "08:39:19",
                "tz": "UTC",
                "tz_offset": "+0000",
                "weekday": "日曜日",
                "weekday_number": "0",
                "weeknumber": "33",
                "year": "2022"
            },
            "vsan_cluster_uuid": null,
            "vsan_health": "unknown",
            "vsan_node_uuid": null
        },
        "changed": false,
        "failed": false
    }
}

PLAY RECAP *********************************************************************************************************
esxi01                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

ESXi上に仮想マシンを作成するPlaybook

Playbookのファイルの記載内容は大きく以下のように構成される。

設定項目 説明
hosts 実行対象のサーバを記載する。サーバのリストは別ファイルで作成し、そのファイルの中で実行する対象のサーバやグループを指定する。
vars 変数を記載する。ここで記載した変数は{{ 変数名 }}という形で参照できる。また、変数は配列して複数の要素を持たせることもできる。
tasks Ansibleで実行するメインの処理を記載する。
handlers Ansibleでメイン処理実行状況に応じて実行する事後処理を記載する。例えば、設定ファイル更新がされた場合 (実行結果がchangedの場合) は設定反映のためにサービス再起動を行うといった使い方をする。今回のPlaybookでは未使用となる。

今回はcreate_vmware_vm.ymlというファイル1つにすべての内容を記載して作成した。以下にそれぞれの記載内容を説明する。

hosts : 実行対象のESXiを指定

hostsというファイル名で以下の通り1台のESXiを記載したインベントリーファイルを作成した。

[vmware_servers]
esxi01 ansible_host=192.168.1.1

vars : 変数①(ESXiに接続するための変数)

変数名 内容
ansible_connection ESXiへの接続の場合はlocalhostを使用する。
ansible_python_interpreter Pythonの実行パスを指定する。これを指定しない場合、「The error was: ModuleNotFoundError: No module named 'pyVim'」といったモジュールが見つからないというメッセージが表示され、タスクの実行に失敗する。
esxi_username ESXiへ接続するためのユーザ名を指定する。
esxi_password ESXiへ接続するためのパスワードを指定する。平文で記載するとセキュリティ上よろしくないので、Ansible Vaultを使って暗号化して記載しよう。
  vars:
    ansible_connection: local
    ansible_python_interpreter: /usr/bin/python3.8
    esxi_username: root
    esxi_password: !vault |
      $ANSIBLE_VAULT;1.1;AES256
      37316332366436396537613265366334323663646463306163353665323836636362323334313763
      ~(中略)~
      3730

vars : 変数②(仮想マシンのパラメータ)

変数名 内容
vm_name 仮想マシン名を指定する。
vm_annotation 仮想マシンの注釈を指定する。
vm_folder 仮想マシンのフォルダを指定する。ESXiにはフォルダの概念がないが、指定が必須となる。この場合は/を指定する。
vm_guest_id 仮想マシンのOS種別を指定する。OS種別とIDの紐づけはVMwareのドキュメントを参照。今回はother4xLinux64Guestを指定する。
vm_hardware 仮想マシンのハードウェアとして、CPU数とメモリ容量を指定する。
vm_disk 仮想マシンのハードデイスクを指定する。
vm_networks 仮想マシンのNICを指定する。
vm_cdrom 仮想マシンの光学ドライブを指定する。今回はOSのインストールメディアであるISOファイルをマウントさせるため、ISOファイルのパスを指定する。
vm_boot 起動時にEFIを使用し、セキュアブートを有効化するよう指定する。
vm_usb_type USBコントローラとして、USB 2.0のコントローラを指定する。
  vars:
      ~(中略)~
    vm_name: ansible-test
    vm_annotation: "Create Ansible"
    vm_folder: /
    vm_guest_id: other4xLinux64Guest
    vm_hardware:
      num_cpus: 2
      num_cpu_cores_per_socket: 2
      memory_mb: 2048
    vm_disk:
      size_gb: 16
      type: thin
      datastore: Datastore-01
    vm_networks:
      name: Network_01
      device_type: vmxnet3
    vm_cdrom:
      iso_path: '[nfs_01] ISO/AlmaLinux/AlmaLinux-8.5-x86_64-minimal.iso'
    vm_boot:
      boot_firmware: efi
      secure_boot_enabled: true
    vm_usb_type: usb2

tasks : 処理内容

VMwareのAnsibleモジュールでは、毎回実行対象ESXiのホスト名、ユーザ名、パスワード、証明書検証の無効化を指定する必要があるため、以下4行を各タスクに設定するようにしよう。

        hostname: "{{ inventory_hostname }}"
        username: "{{ esxi_username }}"
        password: "{{ esxi_password }}"
        validate_certs: false

各タスクの処理概要を以下に記載する。
※モジュール名はFQCNで記載すると長くなるため名前だけの記載にしているが、PlaybookにはFQCNで記載することを推奨する。

タスク名 モジュール 設定
Create vm vmware_guest 仮想マシンを作成する。作成する仮想マシン名nameを指定し、CPU、メモリ、光学ドライブ、ディスク、ネットワークなどを設定する。ただし、一部起動時の設定やUSBコントローラの追加はできないため、それについては他タスクにて対応する。
Set boot settings vmware_guest_boot_manager 起動時BIOS/EFIの設定を行う。
Set usb controller vmware_guest_controller USBコントローラを追加する。
  tasks:
    # 仮想マシン作成
    - name: Create vm
      community.vmware.vmware_guest:
        hostname: "{{ inventory_hostname }}"
        username: "{{ esxi_username }}"
        password: "{{ esxi_password }}"
        validate_certs: false
        name: "{{ vm_name }}"
        annotation: "{{ vm_annotation }}"
        folder: "{{ vm_folder }}"
        guest_id: "{{ vm_guest_id }}"
        hardware:
          num_cpus: "{{ vm_hardware.num_cpus }}"
          num_cpu_cores_per_socket: "{{ vm_hardware.num_cpu_cores_per_socket }}"
          memory_mb: "{{ vm_hardware.memory_mb }}"
        cdrom:
          - controller_number: 0
            controller_type: sata
            unit_number: 0
            iso_path: "{{ vm_cdrom.iso_path }}"
            type: iso
        disk:
          - size_gb: "{{ vm_disk.size_gb }}"
            type: "{{ vm_disk.type }}"
            datastore: "{{ vm_disk.datastore }}"
        networks:
          - name: "{{ vm_networks.name }}"
            device_type: "{{ vm_networks.device_type }}"
            start_connected: true
        state: present

    # BIOS/EFI設定
    - name: Set boot settings
      community.vmware.vmware_guest_boot_manager:
        hostname: "{{ inventory_hostname }}"
        username: "{{ esxi_username }}"
        password: "{{ esxi_password }}"
        validate_certs: false
        name: "{{ vm_name }}"
        boot_firmware: "{{ vm_boot.boot_firmware }}"
        secure_boot_enabled: "{{ vm_boot.secure_boot_enabled }}"

    # USBコントローラ設定
    - name: Set usb controller
      community.vmware.vmware_guest_controller:
        hostname: "{{ inventory_hostname }}"
        username: "{{ esxi_username }}"
        password: "{{ esxi_password }}"
        validate_certs: false
        name: "{{ vm_name }}"
        controllers:
          - state: present
            type: "{{ vm_usb_type }}"

実行結果

実際にPlaybookを実行した結果を以下に記載する。

# ansible-playbook -i hosts create_vmware_vm.yml 

PLAY [Create vmware vm] *********************************************************************************************

TASK [Gathering Facts] **********************************************************************************************
ok: [esxi01]

TASK [Create vm] ****************************************************************************************************
changed: [esxi01]

TASK [Set boot settings] ********************************************************************************************
changed: [esxi01]

TASK [Set usb controller] *******************************************************************************************
changed: [esxi01]

PLAY RECAP **********************************************************************************************************
esxi01                  : ok=4    changed=3    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

実際にESXi上で作成した仮想マシンを確認すると、設定したパラメータ通りに作成が成功していた。


Ansibleを使ってESXi上に仮想マシンを構築するPlaybookの説明は以上となる。

参照

2022年4月2日土曜日

vCenter Server Appliance 7.0のバックアップ&リストア手順

vCenter Server Appliance (以下、vCSA) では、バックアップファイルを外部のファイルサーバなどに出力する機能が備わっており、VMwareとしても推奨するバックアップ手法となる。

今回、実際にバックアップファイルを出力しリストアを実施してみた。本記事では、vCSAのバックアップをCIFSファイルサーバに出力し、出力したバックアップファイルからリストアする手順を記載する。

環境

環境としてはvSphere 7.0を用いる。2台のvCSAを構築して拡張リンクモードで構成し、片方のvCSAをリストアしても、拡張リンクモード含め問題なく復旧できることを確認する。

  • vCenter Server : 7.0 Update 1d
  • ESXi : 7.0 Update 1c
  • CIFSファイルサーバ : QNAP TS-231P

バックアップ手順

1. アプライアンス管理画面にログイン

vCSAのバックアップはvSphere Clientではなく、vCSAのアプライアンス管理画面 (ポート番号5480) にて行う。

https://[vCSAのIPアドレス]:5480/

アプライアンス管理画面は、rootまたはSSO管理者 (例えば[email protected]) でログインする。

2. バックアップを取得

アプライアンス管理画面のメニューより「バックアップ」から「今すぐバックアップ」ボタンを選択すると、1回限りのバックアップを取得できる。

なお、スケジュールを設定して定期的にバックアップを取得することも可能となる。通常は、日次などでバックアップ取得するようスケジュール設定すべきだろう。

バックアップは以下の設定項目がある。以下に各説明項目を記載する。

設定項目 説明
バックアップの場所 バックアップの場所を指定する。[プロトコル名]://[バックアップサーバのIPアドレス]/[フォルダ]といった形式で指定する。対応するプロトコルは、FTPS、HTTPS、SFTP、FTP、NFS、SMB、HTTPを指定できる。今回はSMBを指定する。
バックアップサーバの認証情報 バックアップファイル保存に必要な権限を持つユーザ、パスワードを入力する。
暗号化バックアップ バックアップファイルを暗号化する場合はパスワードを設定する。
DBの健全性チェック バックアップ時にDBの健全性チェックを行う場合はチェックする。デフォルトは有効であるため、特に理由がなければ有効で問題ない。
データ データに統計情報やイベントを含める場合はチェックする。サイズを削減したいなどの理由がある場合のみ無効にすればよいだろう。

3. バックアップ完了まで待機

バックアップ完了まで待機する。

私の環境のvCSAはほぼ新規構築状態となるため、バックアップファイルは約240MBとなり、バックアップは1分で完了した。

リストア手順

1. ESXiにログインしvCSAを登録解除

vCSAのリストア時に同じESXi上に元のvCSAが存在する場合、仮想マシン名が重複することにより、リストア時にエラーとなる。そのため、事前にESXiのVMware Host Clientにログインし、vCSAのシャットダウンとESXiからの登録解除を実施しておこう。

2. vCSAのインストーラよりリストアを開始

vCSAのISOイメージに含まれるinstaller.exeを起動しvCSAのインストーラを起動すると、「リストア」の選択項目があるため、それを選択する。

リストアは以下の設定項目がある。以下に各説明項目を記載する。

設定項目 説明
バックアップの詳細を入力 ここではリストア時と同様に、バックアップサーバのIPアドレスと認証情報を設定する。
vCenter Server のデプロイ ターゲット vCSAリストア先のESXiのIPアドレスを設定する。
ターゲット vCenter Server 仮想マシンのセットアップ リストアするvCSAの仮想マシン名とrootパスワードを設定する。通常は元のvCSAと同一の設定で問題ないだろう。なお、このタイミングで仮想マシン名の重複チェックがされるため、前段の手順で実施したvCSAの登録解除は必ず実施しておく必要がある。もし重複する場合は、「ターゲットに同じ名前の仮想マシンまたはテンプレートが存在するかどうかを確認中に問題が発生しました」のエラーでインストールを進めることができない
デプロイ サイズの選択 元のvCSAのサイズを選択すれば問題ない。
データストアの選択 vCSAが稼働するだけの十分な空き容量があるデータストアを選択する。
ネットワークの設定 元のvCSAのIPアドレス設定をすれば問題ない。

上記設定完了後、vCSAのデプロイが開始する。

3. 展開したvCSAにてリストアを実施

ここまではvCSAの通常のインストールウィザードと同様となるが、ここから先がリストアの場合は異なる。

以下に設定項目を記載する。

設定項目 説明
バックアップの詳細 ここは前述した手順で指定した情報から変更ができないが、バックアップに暗号化パスワードを設定していた場合は、解除パスワードを指定する。
Single Sign-On 構成 元のvCSAのSSO管理者のユーザ名とパスワードを入力する。通常は[email protected]を選ぶことになるだろう。

上記設定完了後、リストアが開始する。

4. リストア完了まで待機

リストア完了まで待機する。リストア状況の進捗は表示されるが、97%になってから少し時間を要するので、気長に完了を待つこと。とはいっても、私の環境では、10分程度で完了した。

問題なく完了すると、「このvCenter Serverは正常にリストアされました」とメッセージが表示される。

5. リストア後の確認

リストア後、再度vSphere Clientでログインしてみよう。

なお、私の環境ではなぜか404のエラーでうまくログインできない事象が発生したが、一度ブラウザのキャッシュクリアやブラウザの落とし上げをしたり、少し時間をおいてからログインを試みると正常にログインできた。

ログインに成功すると、以下図の通り一台のvCSAは「親 (実体) なし」で表示され、リストアしたvCSAは末尾に「(1)」が名前に付与されていることがわかる。元のvCSAの情報がゴミとして残ってしまい「親 (実体) なし」となっているようだ。これは次の手順でインベントリから削除すれば問題ない。

また、左側のツリーには拡張リンクモードしている2台のvCSAが存在しており、リストアしても問題なく拡張リンクモードの構成は維持されていることが確認できる。

6. vCSAの仮想マシン名を修正

「親 (実体) なし」のvCSAは不要となるため、「インベントリから削除」する。インベントリから削除したのち、リストアしたvCSAを正しい名前に修正する。

以上で、vCSAのバックアップファイルからのリストアは完了となる。

参考

2022年3月19日土曜日

【Zabbix/ESXi】snmptrapdにてSNMP v3のTrapを受信する

SNMPを使って監視をする場合、現在でもv1やv2cを使うことが多い。SNMP v1やv2cは、ほとんどの機器で対応がされていることや、コミュニティ名のみ設定が完了するといったシンプルな面で現在も根強く使われているものと想定される。

しかし、SNMP v2c以前のバージョンでは通信が暗号化されないなどの脆弱な要素もある。SNMP v3を使えば、ユーザ名、認証パスワード、暗号化パスワードを設定することができるようになっており、ユーザ単位での認証と通信暗号化ができるようになっている。
※なお、SNMP v3では通信暗号化の機能を「プライバシー」と呼ぶ。

今回、ZabbixのSNMP Trap受信時に使用する「snmptrapd」にて、SNMP v3のTrap受信設定を行うための手順を記載する。SNMP v3 Trap送信側としては、ESXiを利用することにする。

なお、Zabbixではsnmptrapdで受信したTrapをsnmpttにて変換を行い監視する仕組みとなるが、snmpttやZabbix本体の設定変更は特に不要であることを確認している。

環境

  • SNMP v3 Trap受信側: Zabbix 5.0 / snmptrapd
  • SNMP v3 Trap送信側 : ESXi 6,7

SNMP v3 Trap送信設定 (ESXi)

1. Engine IDの設定

SNMP v3を利用する場合、Trap送信元を一意に識別するためのEngine IDを指定する。機器によっては自動生成されるIDとなり、手動での設定は不要となる場合が多い。ESXiの場合も自動生成がされるが、私の環境ではEngine IDが重複したことから、手動で設定することにした。

ESXiのSNMP v3 Trapの設定は、すべてCLIにて行う。ESXiにSSHでログインしたのち、以下コマンドでEngine IDを設定する。Engine IDは5~32 文字の16進文字列であれば、任意で設定して問題ない。

# esxcli system snmp set --engineid 800000000000192168001001

2. SNMP v3の認証・暗号化プロトコルを指定

SNMP v3では認証に使用するプロトコルと、暗号化に使用するプロトコルをそれぞれ設定することができる。

認証プロトコルはMD5またはSHAを選択することができるが、具体的には以下プロトコルとなる。
RFC 3414RFC3826より確認。

  • HMAC-MD5-96
  • HMAC-SHA-96

暗号化プロトコルは当初CBC-DESのみ使用可能だったようだが、機能拡張がされており、AESによる暗号化にも対応している。

  • CBC-DES
  • CFB128-AES-128

なお、RFCとしては上記2種類がサポートされる状況はあるが、暗号化強度が弱いことから、独自にAES256などに対応するパターンもあるようだ。当然だが、SNMP v3 Trap送信側と受信側双方で同じ暗号化方式に対応している必要がある。

ESXiの場合は、RFC準拠のSHA1とAES128の一択となるため、以下の通り設定を行う。

# esxcli system snmp set --authentication SHA1
# esxcli system snmp set --privacy AES128

3. SNMP v3のユーザ、パスワード設定

認証パスワードと暗号化パスワードを以下の通り設定する。

  • 認証パスワード : v3authPass
  • 暗号化パスワード : v3privPass

ESXiの場合パスワードをそのまま指定ができないため、以下コマンドでハッシュ化した文字列を取得する。

# esxcli system snmp hash --auth-hash v3authPass --priv-hash v3privPass --raw-secret
   Authhash: af248a5ff20f816a70121031ba4e9fd69a44b6e5
   Privhash: fcec9a30a5454d50755efeee8f171cceaa9db702

ハッシュ値を確認したら、以下の構文で設定を行う。

esxcli system snmp set -u [ユーザ名]/[認証パスワードのハッシュ]/[暗号化パスワードのハッシュ]/priv

設定例は以下となる。

# esxcli system snmp set -u trapuser/ce534f0992ccea99c435360c52f25c3ea550a933/6fa4e7b290552b6c7c88112fdf3fc1e56e54948b/priv

4. SNMP v3 Trapの送信設定

Trap送信先を指定する。構文は以下の通り

esxcli system snmp set --v3targets [Trap送信先]@162/[ユーザ名]/priv/trap

設定例は以下となる。

# esxcli system snmp set --v3targets 192.168.1.2@162/trapuser/priv/trap

5. SNMP有効化と設定確認

最後にSNMP有効化と設定確認を行う。

# esxcli system snmp set --enable true

# esxcli system snmp get
   Authentication: SHA1
   Communities: public
   Enable: true ←★trueであること
   Engineid: 800000000000192168001001
   Hwsrc: indications
   Largestorage: true
   Loglevel: info
   Notraps: 
   Port: 161
   Privacy: AES128
   Remoteusers:
   Syscontact:
   Syslocation:
   Targets:
   Users: trapuser/ce534f0992ccea99c435360c52f25c3ea550a933/6fa4e7b290552b6c7c88112fdf3fc1e56e54948b/priv
   V3targets: 192.168.11.24@162 trapuser priv trap

以上でESXiにおけるSNMP v3 Trapの送信設定は完了となる。

SNMP v3 Trap受信設定 (snmptrapd)

1. snmptrapd.confを設定

snmptrapdの設定はSNMP v2と同様、/etc/snmp/snmptrapd.confに設定追加を行う。

createUser -e 0x[Engine ID] [ユーザ名] SHA [認証パスワード] AES [暗号化パスワード]
authUser log,execute,net [ユーザ名]

設定例は以下の通り。先ほど設定したESXiと同一のEngine ID、ユーザ名、認証パスワード、暗号化パスワードを設定する。

# cat /etc/snmp/snmptrapd.conf
/usr/bin/bin/my_great_script cold

createUser -e 0x800000000000192168001001 trapuser SHA v3authPass AES v3privPass

authUser log,execute,net trapuser
authCommunity   log,execute,net public
traphandle default /usr/sbin/snmptthandler

2. snmptrapdを再起動

設定反映のためsnmptrapdを再起動する。注意事項として、設定反映のためにはなぜか2回再起動が必要となるので注意する。

# systemctl restart snmptrapd
# systemctl restart snmptrapd

実際の設定は/var/lib/net-snmp/snmptrapd.confに記載される。念のため、設定が反映されていることを確認しておこう。usmUserから始まる行が追加されていれば問題ない。

# cat /var/lib/net-snmp/snmptrapd.conf | grep usmUser
usmUser 1 3 0x800000000000192168001001 "trapuser" "trapuser" NULL .1.3.6.1.6.3.10.1.1.3 0xaf248a5ff20f816a70121031ba4e9fd69a44b6e5 .1.3.6.1.6.3.10.1.2.4 0xfcec9a30a5454d50755efeee8f171cce 0x

3. SNMP v3 Trap受信確認

最後にSNMP v3 Trapを受信できることを確認する。ESXiからは以下コマンドにてテストTrapの送信が可能となる。

# esxcli system snmp test
   Comments: There is 1 target configured, send warmStart requested, test completed normally.

snmptrapdでログが受信したかどうかは/var/log/messagesを確認すればよい。

# tail -1 /var/log/messages
Sep  4 17:26:17 localhost snmptrapd[29984]: 2021-09-04 17:26:17 <UNKNOWN> [UDP: [192.168.1.1]:26522->[192.168.1.2]:162]:#012.1.3.6.1.2.1.1.3.0 = Timeticks: (120893100) 13 days, 23:48:51.00#011.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.6.3.1.1.5.2

参考までにZabbixの管理画面でも監視状況を確認したところ、問題なくSNMP v3のテストTrapの監視ができていることが確認できた。

【参考】snmptrapdの設定削除

snmptrapdの設定追加後、不要になったTrap受信設定を削除したい場合、/etc/snmp/snmptrapd.confの設定を削除するだけでは、設定削除されない。したがって、直接/var/lib/net-snmp/snmptrapd.confから不要な設定を削除する。

なお、サービスを停止してから設定削除を行う必要があるので注意すること。もしサービス起動状態で設定削除を行っても、サービス再起動をすると設定が戻ってしまう。

# vi /etc/snmp/snmptrapd.conf ←★事前に設定を削除

# systemctl stop snmptrapd ←★サービスを停止
# sed -ie '/^usmUser.*/d' /var/lib/net-snmp/snmptrapd.conf ←★usmUserで始まる行をすべて削除

# systemctl start snmptrapd ←★サービス起動
# systemctl restart snmptrapd ←★設定反映のためサービス再起動

参考

2022年1月29日土曜日

「Windows 11 development environment」をESXi 7.0上に展開する手順

Windows 10の次期OSとして登場したWindows 11は、OSのハードウェア要件が厳しく、古いPCへのインストールはできず、仮想環境などへの導入も困難と思われていた。

しかし、「Windows 11 development environment」を使うとESXi 7.0の仮想マシンとしてWindwos 11を動作させることができる

「Windows 11 development environment」は、Windwos 11に各種開発ツールがインストールされた開発用OSとして、期間限定ではあるが無償提供されている。

今回、「Windows 11 development environment」をESXi 7.0上に展開し、要件を満たしていない環境においてもWindows 11を動作させる手順を記載する。

環境

Windows 11を展開する環境は以下の通り。後述するが、仮想マシンのハードウェアバージョンの関係上、ESXi 7.0 Update 1以降でなければ展開できないため注意すること。

  • vCenter Server 7.0 Update 1d
  • ESXi 7.0 Update 1c

「Windows 11 development environment」展開手順

1. 「Windows 11 development environment」のダウンロード

「Windows 11 development environment」は以下URLからダウンロードできる。

注意事項としては以下となる。

  • 使用できる期間が決まっており、2022年1月時点では「2022年3月4日」が期限となる。おそらく、その期限に近づくと新たなOSイメージ提供されダウンロードできるようになると想定される。
  • OSイメージは、VMware、Hyper-V、VirtualBoxといった各種仮想環境用のファイルをダウンロードできる。
  • OSイメージは20GBもあるので注意!また、zip圧縮されているため、解凍する際も時間と容量を使うため注意。
  • 仮想マシンのハードウェアバージョンはvmx-18となり、ESXi 7.0 U1 (7.0.1) 以降でなければ展開できないので注意。

今回はESXi 7.0上にインストールするため、VMware用のファイルをダウンロードする。20GBもあるので、回線帯域が細い場合は気長にダウンロード完了を待とう。

ダウンロードが完了したzipファイルを解凍を行うと、以下内容となっていた。

  • WinDev2110Eval.mf
  • WinDev2110Eval.ovf
  • WinDev2110Eval-disk1.vmdk

試してはいないが、OVFファイル (.ovf)の中身のハードウェアバージョンを修正し、マニフェストファイル (.mf) のSHA-256のハッシュ値を更新すれば、ひょっとしたらESXi 7.0以前のバージョンにも展開できる可能性はある。

2. ESXi 7.0にOVFテンプレートのデプロイ

vSphere ClientやVMware Host Clientなどを使って、ダウンロードしたOVFファイルをESXi上に展開する。特に通常のOVFテンプレートと同様の手順にて展開すれば問題ない。

3. Windows 11の仮想マシンを起動

展開後、Windows 11の仮想マシンを起動してみると、何事もなくWindows 11のデスクトップが表示される。

vCenter Serverにて確認した仮想マシン情報は以下の通り。Windows 11ではあるが、ゲストOSの種別はWindows 10として扱っているようだ。

以上で、「Windows 11 development environment」をESXi 7.0上に展開する手順は完了となる。

2022年1月22日土曜日

Kickstartを使ってESXiを自動インストールする

自宅でNested ESXiの環境を構築し、vCenter Serverを頻繁にインストールして検証などを行っている。ESXiは設定項目が多くないので、インストール自体はそこまで時間を要するものではないが、効率よくインストールできるよう、Kickstart (キックスタート) を使ってESXiのインストールの自動化を試してみた。

なお、KickstartはRed Hat系のLinuxディストリビューションでも同様の機能を有しており、大まかな使い方としては同じとなるが、細かいところで差異があるので注意。

Red Hat系のLinuxディストリビューションのKickstartの使い方は、以下記事を参照いただきたい。

環境

Kickstartの検証はESXi 6.7上に構築したESXi 6.7 (Nested ESXi) で実施した。注意事項として、Nested ESXiを構築する場合、デフォルトで有効となっているUEFIセキュアブートを無効にすること。UEFIセキュアブートが有効の場合、初回起動後に実行する%firstbootに記載したコマンド実行に失敗するので注意。

Kickstart用のファイルの配置先はQNAP NASを用いることとし、接続プロトコルはNFSを利用する。なお、NFS v4のみ有効にすると失敗するため、必ずNFSサーバ側でNFS v3を有効にすること。

手順

1. Kickstartファイル (ks.cfg) を作成

Kickstartは、インストール情報を定義したKickstartファイルと呼ばれるファイルを読み込ませることで自動インストールを実現する。このファイルは通常ks.cfgというファイル名で作成をするのが一般的となるが、ファイル名は任意で設定して問題ない。

Kickstartファイルは、インストール時に各種設定を定義するためのコマンドやオプションが用意されている。詳細は公式マニュアルを参照いただきたいが、最低限必要となるコマンドについては、以下表にて説明する。

設定項目 設定コマンド 説明
利用規約 (EULA) への同意 vmaccepteula 利用規約への同意を自動で行う設定。
rootパスワード rootpw 平文 (オプションなし) またはハッシュ化 (--iscrypted) した文字列でパスワードを指定できる。ハッシュ化したパスワードは、インストール済みのLinux環境の/etc/shadowから抽出すると楽。
インストール設定 install インストール対象のディスクを選択する設定。--firstdiskでローカルディスクの最初のディスクを選択し、--overwritevmfsで既存のVMFS領域を上書きする。VMFS領域を残したり、そもそも作成しないといったオプションも設定可能。
キーボードレイアウト keyboard キーボードレイアウトを指定。Japaneseを選んでおけば問題ない。
ネットワーク network ホスト名やIPアドレスなどの設定。Red Hat系のnetworkの設定方法と同様となる。
インストール後の動作 reboot インストール後に自動で再起動かける場合に指定。デフォルトで再起動時にDVDのイジェクトが行われるが、イジェクトしない場合は、--noejectを付与する。
初回起動後のコマンド実行 %firstboot ESXiインストール後の初回起動後にコマンドを実行させる。--interpreter=busyboxを付けることで、通常のESXi Shellによるコマンド実行が可能となる。

以下に私が実際に使用しているKickstartファイルを例として記載する。

# Accept the VMware End User License Agreement
vmaccepteula

# Set the root password for the DCUI and Tech Support Mode
rootpw mypassword
#rootpw --iscrypted XXXX~(省略)~XXXX

# Install on the first local disk available on machine
install --firstdisk --overwritevmfs

# Keyboard type
keyboard Japanese

# Set the network
#network --bootproto=dhcp --device=vmnic0
network --bootproto=static --ip=192.168.11.161 --netmask=255.255.255.0 --gateway=192.168.11.31 --nameserver=192.168.11.61,192.168.11.62 --device=vmnic0 --hostname=t1161esxi

# Reboot after installation
reboot

%firstboot --interpreter=busybox

# Enable ssh
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh

# Enable ESXi Shell
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell

# Suppress Shell Warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1

# Enable NTP
echo 'server 192.168.33.23 iburst' >> /etc/ntp.conf
chkconfig ntpd on
/etc/init.d/ntpd start

# Disable IPv6
esxcli system module parameters set -m tcpip4 -p ipv6=0 

reboot

2. NFSサーバにKickstartファイルを配置

作成したKickstartファイルは、OSインストール時に読み込ませる必要がある。いくつか方式はあるが、今回はNFSサーバにKickstartファイルを配置して、ネットワーク経由で読み込みさせることにする。

NFSサーバの構築は本題とは関係がないため割愛するが、今回はQNAP NASをNFSサーバとして使用することにした。前述したとおり、NFS v4では失敗するためNFS v3を有効にすること。

配置パスは以下となる。Red Hat系とパスの構文が微妙に異なるので注意。

nfs://192.168.11.13/Public2/ks/ks_esxi.cfg

3. OSインストールメディアで起動

通常通りESXiのインストールメディアにて起動し、最初の画面に「Shift + o (シフト + オー)」を押すと、インストールパラメータを指定する画面に遷移する。「Shift + 0 (シフト + ゼロ)」ではないので注意。

4. インストールパラメータでKickstartファイルを指定

インストールパラメータでは、以下の通り、ksのパラメータを追記する。くどいが、Red Hat系とパスの構文が微妙に異なるので注意。

cdromBoot runweasel ks=nfs://192.168.11.13/Public2/ks/ks_esxi.cfg

パラメータ追記後、「Enter」を押してインストールを開始する。

5. 自動インストール開始

Kickstartによる自動インストールが成功した場合は、以下画面のように「Reading installation script」といった表示がされ、自動的にインストールが進むはずだ。

インストール完了後、「ESXi 6.7.0 has been installed successfully」と表示され、少し待つと自動でESXiが再起動する。

6. 初回起動後のスクリプト実行

初回起動後は、%firstbootで指定されたコマンドが実行される。私のKickstartファイルでは、IPv6無効化の反映のために%firstbootの最後にrebootを設定しているため、自動的にESXiが再起動する。

再起動、いつものESXiのDCUIが表示されればインストール完了となる。

7. インストール後の確認

インストール完了後、SSHでログインし以下であることを確認した。Kickstartにより問題なく初期設定がされていることが確認できた。

  • SSHが有効化されていること
  • ESXi Shellが有効化されていること
  • SuppressShellWarningが1で設定されていること
  • ntpdサービスが起動し、NTPサーバと同期していること
  • IPv6が無効化されていること
[root@t1161esxi:~] chkconfig SSH
SSH                     on

[root@t1161esxi:~] chkconfig ESXShell
ESXShell                on

[root@t1161esxi:~] esxcli system settings advanced list -o /UserVars/SuppressShe
llWarning
   Path: /UserVars/SuppressShellWarning
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Don't show warning for enabled local and remote shell access

[root@t1161esxi:~] chkconfig ntpd
ntpd                    on
[root@t1161esxi:~] ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.33.23   133.243.238.164  2 u   46   64   37    0.428   -0.242   0.617

[root@t1161esxi:~] esxcli system module parameters list -m tcpip4
Name                 Type  Value  Description
-------------------  ----  -----  --------------------------------
ipportIscsiReserved  int          # of provisioned H/W iSCSI ports
ipv6                 int   0      Enable/Disable IPv6

ここからさらにvCenter Server Appliance (vCSA) もCLIベースでインストールすることで、最短でvSphereの検証環境を構築することができる。vCSAのCLIベースでのインストール手順は、以下を参照いただきたい。

参考

更新履歴

  • 2021/6/1 新規作成
  • 2022/1/22 Kickstartファイルを配置するNFSサーバーはNFS v3を有効にする必要がある旨追記

人気の投稿