ESXiでユーザ名の入ったパスワードが設定できないので設定を変えた


ESXi 6.7, ESXi 7.0 の単体環境で、テスト用のユーザを「test」で作成し、パスワードを「test.1234!」で設定しようとしたところエラーとなった。

画像

「弱いパスワード: 個人ログイン情報に基づいています」

Create User
キー  haTask-ha-folder-root-vim.host.LocalAccountManager.createUser-960490766
説明  ローカル ユーザー アカウントを作成します
フォルダ:
状態  失敗 - 一般的なシステム エラーが発生しました: Weak password: based on personal login information. *** passwd: Authentication token manipulation error

エラー 弱いパスワード: 個人ログイン情報に基づいています。

ただ、パスワードを「test.1234!a」と1文字付け加えるだけで設定は可能だった。

怪しい設定としては「VMware Host Client でのパスワードとアカウント ロックアウト ポリシーの構成」にある「Security.PasswordQualityControl」設定となる。

標準では「retry=3 min=disabled,disabled,disabled,7,7」となっている。

これを解釈すると

「retry=3」パスワード間違い3回まで許容
「min=disabled,disabled,disabled,7,7」 min=N0,N1,N2,N3,N4
  N0: 1種類の文字だけの場合。disabledなので不許可
  N1: 2種類の文字のパスワードの場合。disabledなので不許可
  N2: パスフレーズの最小文字列。disabledなので不許可
  N3: 3種類の文字のパスワードの場合。7文字以上必要
  N4: 4種類の文字のパスワードの場合。7文字以上必要

ということになる。

なぜユーザtestの場合、「test.1234!」がダメなのか、と考えると、おそらく、testが文字種別としてカウント対象外となり「.1234!」のみで判断しているためではないだろうか?ということになる。

「.1234!」は数字と記号の2種類だけなので、disabledで不許可。
「.1234!a」は 数字と記号 と英語小文字の3種類あり、7文字以上なので許可。

では、2種類だけであっても通るようにすればいいのか、と 「retry=3 min=disabled,7,disabled,7,7」 と設定してみたところ、エラー・・・

画像
Update User
キー   haTask-ha-folder-root-vim.host.LocalAccountManager.updateUser-960491342
説明   ローカル ユーザー アカウントを更新します

フォルダ:
状態   失敗 - 一般的なシステム エラーが発生しました: pam_passwdqc: Error parsing parameter "min=disabled,7,disabled,7,7": Invalid parameter value. *** passwd: Critical error - immediate abort

エラー

「retry=3 min=7,7,7,7,7」 でもエラーになった・・・

しかし、なぜか「 retry=3 min=8,8,8,7,7」だとエラーとならずに、パスワード変更が完了した。

なぜ????

ちなみに、なぜ8で設定してみようと思ったかは「ESXi 6.5 & later Password policy」「ESXi 7 Password policy」で例としてあげられていたためなんですが、問題はこのページだと「disabled」は「8」に相当するって書いてあること。

ほんとにdisabled=8なんだろうか???「14」と設定できることを考えるとあやしいなぁ・・とは思っている。

vSphere 7.0 Update 1以降 vCLSという仮想マシンが勝手に起動してUPS連動シャットダウンに失敗する


vSphere 7.0 Update 1にアップデートして以降、UPS連動シャットダウンに失敗するようになった。

ログを確認していくと、仮想マシンがシャットダウンできない模様。

しかし、vCenter Serverから確認しても動いている仮想マシンは見えない。

そこでESXi のHost Clientに接続して確認すると、vCLSという作った覚えない仮想マシンが起動している。
そして、vCLSを手動で停止しても勝手に起動してくる。

確認してみると、vSphere 7.0 Update 1以降、vSphere DRS/vSphere HAなどのクラスタについて、起動するまでに時間がかかり重いvCenterサーバ仮想マシンではなく、クラスタの可用性のみを面倒見る仮想マシンとして vSphere Cluster Services を提供するようになったようである。

vSphere 7.0 Update 1 の vSphere Cluster Services (vCLS) (80472)
vSphere 7.0 documentation 「vSphere Cluster Services (vCLS)

これをUPS連動シャットダウンと組み合わせる場合の資料を探したところ、下記があった。

APC「PowerChute Network Shutdown v4.3/v4.4によるvSphere 7.0 Update 1でのvCLSの制御について
DELL「もう迷わない!HCI環境のUPS選定 シャットダウンについて

vSphereのクラスタをのvCLSをRetreatモードに変更することでvCLS仮想マシンが停止/削除することができる、というもの。

PowerShellでvCenterに接続して下記の様なスクリプトを実行して無効化を実行(APCのサンプルスクリプト disable_HA.ps1)

#!/usr/bin/pwsh

$server = "10.179.232.198" #"provide Vcenter server IP/hostname"
$username = "pcnsadmin" #"provide username to access vCenter"
$password = "APCapc@123" #"Provide Password to access vCenter server"
$cluster = "C" #"provide Name of the Cluster where Retreat mode needs to be enabled"

$env:HOME = '/root'
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false
Connect-VIServer $server -Protocol https -User $username -password $password
$clid = (Get-Cluster $cluster).ID
Write-Host $clid
$myclid = $clid -replace 'ClusterComputeResource-',''
Write-Host $myclid
Get-AdvancedSetting -Entity $server -Name config.vcls.clusters.${myclid}.enabled | Set-AdvancedSetting -Value False -Confirm:$false

##Additional step for VSAN to turn off HA on the cluster
Get-Cluster -Name $cluster | Set-Cluster -HAEnabled:$false -Confirm:$false

Disconnect-VIServer -Force -Confirm:$false

PowerShellでvCenterに接続して下記の様なスクリプトを実行して有効化を実行(APCのサンプルスクリプト enable_HA.ps1)

#!/usr/bin/pwsh

$server = "10.179.232.198" #"provide Vcenter server IP/hostname"
$username = "pcnsadmin" #"provide username to access vCenter"
$password = "APCapc@123" #"Provide Password to access vCenter server"
$cluster = "C" #"provide Name of the Cluster where Retreat mode needs to be disabled"

$env:HOME = '/root'
Connect-VIServer $server -Protocol https -User $username -password $password
$clid = (Get-Cluster $cluster).ID
$myclid = $clid -replace 'ClusterComputeResource-',''
Write-Host $myclid
Get-AdvancedSetting -Entity $server -Name config.vcls.clusters.${myclid}.enabled | Set-AdvancedSetting -Value True  -Confirm:$false

##Additional step for VSAN to turn off HA on the cluster
Get-Cluster -Name $cluster | Set-Cluster -HAEnabled:$true -Confirm:$false

Disconnect-VIServer -Force -Confirm:$false

もう1つはAPCの資料および「PowerChute(TM) Network Shutdown v4.3 for Virtualization 補足説明書 日立編」には設定フローと共に掲載されている手法。

PowerChute Network Shutdownで「VM優先度付け」設定を有効にした上でvCLS仮想マシンを「優先度 高」で設定。vCenterサーバ仮想マシンを「優先度 中」、それ以外を優先度 低などに入れる。

「VMシャットダウン所要時間設定」と「VM起動所要時間設定」で「高」と「中」に対して0秒以上の値を設定

仮想化設定にある”仮想マシンと仮想装置、シャットダウンと起動”設定の「仮想マシンvApp 起動」にチェックを入れる

“ホストメンテナンスモード”の「タイムアウト」を「60秒」に設定

というもの。

綺麗に実行するのであればPowerShellを使った手法のほうが良さそうだ。

ESXi 7.0 Update 1からSDカード/USBメモリ起動の場合に書き込み回数性能が重要になった件について


VMware vSphere / ESXi 7.0 から ESXiのブートディスクの構造が変更になった。

VMware vSphere Blog「vSphere 7 – ESXi System Storage Changes
「ESXi のシステム ストレージの概要」の「ESXi 7.0 のシステム ストレージの変更

ESXi 6.0時代 /scratch となっているパーテーションとかあるが、基本的に起動したあとデータ書き込みはあまりないかたちで運用されていた。

ところがESXi 7.0からは細かく分かれていたパーテーションがESX-OSDataパーテーションに統合されている。しかも、ここに書き込みが行われるようになった。

そして、ESXi 7.0 Update 1 / Update 2においてSDカード / USBメモリへの書き込み手法が変更され、起動ディスクに対して従来と比較すると多量の書き込み操作が実行されることになった。

これにより、ESXi 7.0 Update 1 / Update 2において、SDカード/USBメモリ起動にしている場合に、書き換え回数超過によるSDカード/USBメモリのアクセス不可事例が発生しやすくなっているようだ。

VMware KB VMFS-L Locker partition corruption on SD cards in ESXi 7.0 (83376)
VMware Technolopy Network「SD Boot issue Solution in 7.x

上記KB83376を見ると、ESXi 7.0(初期)ではI/O抑制機能があったが、ESXi 7.0 Update 1ではなくなったことが発生しやすくなった要因の1つであるようだ。

しかも、VMware的には「ESXi のシステム ストレージの概要」で、「ESX-OSData は 高耐久性ストレージ デバイス上に作成する必要があります。」と書いてあるから、書き換え回数上限が低いものを使わないのは当然でしょ、というスタンスな模様。

OEMメーカが選定したSDカードなどが死んだとしても、それはその部材を選んだOEMメーカ側の責任だということらしい。

実際、DELLの「VMware vSphere 7.x on Dell EMC PowerEdge Servers Getting Started Guide」の「Getting started with VMware vSphere」をみると、ESXi 7.0ではSDカードは推奨しない、と書いてある。

NOTE: If you had ordered VMware ESXi with your Dell EMC PowerEdge server, it is preinstalled on your server. The ESXi installer media is required for reinstallation. The Boot Optimized Storage Solution (BOSS) card is the preferred non-HDD or SSD device for VMware ESXi 7.0 installation. The Dell Internal Dual SD Module (IDSDM) install is no longer recommended due to write endurance issues with the SD flash media. For more information, see the Storage Requirements for ESXi 7.0 Installation or Upgrade section on the VMware ESXi Installation and Setup Guide or see VMware Knowledge Base article 2145210.

さて、この問題について、とることができる方策は下記の5つが考えられる。

その1) 高耐久性のものに変更する(USB接続のSSDや、MLCチップのSDカードなど)
その2) 普通のSSDやHDD起動に変更する
その3) ESXi 7.0 Update 2用の現象低減パッチが7月中にリリース予定(ただし、低減、である)
      → 2021/08/24リリースのESXi 7.0 U2cで提供開始
その4) メインメモリを消費してRamdiskを作成し、そこに書き込ませる
その5) あきらめて、壊れたら交換&ESXi再セットアップ

その4の手法はVMware KB83376 内にリンクがあり「High frequency of read operations on VMware Tools image may cause SD card corruption (2149257)」で説明されている。

ドキュメント的にはESXi 6.0 と ESXi 6.5用になっているが、ESXi 7.0でも適用できるようだ。

ESXi 7.0のshellに入って、現在の /UserVars/ToolsRamdisk の設定を確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 0
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 0」ということなので、現在は「0」となっている。

これを1に変更するため、以下を実行する

# esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1
#

変更が反映されたか確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 1」となっていたら変更されている。

この後、ESXi を再起動して、RAMディスクを実際に稼働させる。

ESXi設定のバックアップ&リストア

SDカード/USBメモリが壊れることを許容する場合、ESXiの設定ファイルをバックアップしておき、再セットアップ時にリストアする、という手法が考えられる。

手法はVMware KB「ESXi ホストの構成のバックアップ方法 (2042141)

リストアの際、ESXiにIPアドレスを割り当てておく必要がある。


具体的にどれくらいの書き込み要求があるんだろう?と調べて見た。

DELL PartnerSEつぶやきブログ「BOSSってなんだろう?」から、ESXiが要求するSSD/Flashデバイスに対する要求要件が書かれた「vSphere SSD and Flash Device Support (2145210)」を発見

それによると下記のようになっている。

Table 1: SSD/Flash Endurance Requirements 

SSD/Flash Device Use CaseJEDEC Endurance RequirementWorkload CharectizationNotes
Host Swap Cache365 TBW or betterRandom, infrequent writesHost memory rarely overcommitted
3650 TBW or betterRandom, frequent writesHost memory routinely overcommitted
Regular Datastore3650 TBW or better1Virtual Machine workload dependentSize >= 1TB needs more endurance
vSphere Flash Read Cache (VFlash)365 TBW or betterVirtual Machine workload dependentSize <= 4TB
ESXi Boot Device0.5 TBW minimum2
2 TBW recommended2,6
Sequential (WAF <10)Size >= 4GB3
ESXi Coredump Device0.1 TBW minimum2,4Extremely sequential (WAF ~1)Size >= 4GB3,4
ESXi Logging Device64 TBW (dedicated device)
128 TBW (colocated) 2,5
Sequential7
(WAF < 100 block mode, WAF < 10 page mode)
Size >= 4GB2,3

ESXi起動デバイスとしては2TBWぐらいだったものが、ログデバイスとしての128TBWぐらいが要求され、USBメモリ上を仮想マシンを置く用のVMFSデータストアとしての使うとなると3650TBWが要求される、などと、起動ディスクとして使うだけの場合より50倍以上の要求がある、ということがわかった。

そりゃ、あっさり死にますね

ESXiのみ環境でPowerCLIを使ってテンプレートもどきの動作をする手法


vCenterサーバがない、ESXiサーバのみ環境ではテンプレート機能が使用できない。

とはいえ、テンプレート化した仮想マシンの中身を見ると、ふつうと同じく仮想ハードディスクのvmdkファイルが存在しているので、vmdkファイルをコピーして、新規仮想マシンを作成するPowerCLIスクリプトをかけば、似たようなことができるな、と実験。

準備するもの

・PowerCLIをインストールした環境
Windows 10で実行したが、Linux環境にPowerShell+PowerCLIをセットアップしてもいけるはず。

・Windowsの場合、sysprepを実行してシャットダウンしたvmdkファイル
sysprepを実行して、次回起動時に初期セットアップが開始されるようにしたvmdkファイル。
VMware-toolsはインストール済みであることが望ましい。

・Linuxの場合、下記の情報などを削除
RHEL7の仮想化の導入および管理ガイド第4章 仮想マシンのクローン作成によれば
/etc/udev/rules.d/70-persistent-net.rules を削除
/etc/ssh/ssh_host_* を削除
/etc/sysconfig/network-scripts/ifcfg-eth* などから IPADDRESS,NETMASK,HWADDRなどの値削除

スクリプト本体

Import-Module VMware.VimAutomation.Core

#Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

$vcenterserver="ESXiサーバ"
$vcenteruser="ユーザ名"
$vcenterpassword="パスワード"

$targetdatastore="仮想マシンをおくデータストア名"

# 仮想マシンの名前 / ランダムで作成して、あとから変更する手法
$vmnamebase="NewVM_"
$vmnametmp=Get-Random
$vmname=$vmnamebase+$vmnametmp

# 仮想マシンスペックと接続ネットワーク指定
$vcpu=2
$vmem=6
$network="VM Network"

# 指定できるGuestOSのIDを調べるには下記を実行すること
#   PowerCLIがサポートしている一覧 
#   [VMware.Vim.VirtualMachineGuestOsIdentifier].GetEnumValues()
# 代表的なもの
# windows8Server64Guest = Windows2012
# windows9Server64Guest = Windows2016
#$vmguestosid="windows9Server64Guest"

# 元ネタのWindowsが入ったvmdkファイルの指定
# 構築時にBIOS環境かEFI環境のどちらで作ったのか注意
$vmdkfilepath="[データストア名] windows2019/windows2019.vmdk"
$vmguestosid="windows9Server64Guest"
#$vmdkfilepath="[データストア名] win2016/win2016.vmdk"
#$vmguestosid="windows9Server64Guest"
#$vmdkfilepath="[データストア名] win2012/win2012.vmdk"
#$vmguestosid="windows8Server64Guest"
# 上記の元ネタが置いてあるデータストア名を下記でも指定する
$sourcedatastore ="データストア名"

# vCenterまたはESXiサーバに接続
Connect-VIServer -Server $vcenterserver -User $vcenteruser -Password $vcenterpassword -WarningAction 0
# パスワードを書きたくない場合は
# New-VICredentialStoreItem -Host $vcenterserver -User $vcenteruser -Password $vcenterpassword
# を実行すると、資格情報保存域に登録され、以降は下記だけで接続できるようになる
# Connect-VIServer -Server $vcenterserver

$virtualportgroup=Get-VirtualPortGroup -Name $network
$datastore=Get-Datastore -Name $targetdatastore
$vm=New-VM -Name $vmname -NumCpu $vcpu -MemoryGB $vmem -Portgroup $virtualportgroup -Datastore $datastore -DiskStorageFormat Thin -GuestID $vmguestosid -HardwareVersion vmx-14


$olddiskinfo=Get-Vm $vmname|Get-Harddisk # 一時的に作られたディスクの情報を保存
$sourcevmdk=Get-HardDisk -Datastore $sourcedatastore -DatastorePath $vmdkfilepath
# ディスクの削除
Remove-HardDisk -HardDisk $olddiskinfo -Confirm:$false


# コピー先データストアのパスを生成
$targetvmdktmp=$olddiskinfo.Filename
$ed=$targetvmdktmp.LastIndexOf("/")
$targetvmdk=$targetvmdktmp.Substring(0,$ed+1) # コピー先のパス

# OSが入ったvmdkのコピー
$adddiskinfo=Copy-HardDisk -Harddisk $sourcevmdk -DestinationPath $targetvmdk -DestinationStorageFormat Thin

#$vm = get-Vm $vmname
New-HardDisk -VM $vm -DiskPath $adddiskinfo.Filename

Get-ScsiController -VM $vm | Set-ScsiController -Type VirtualLsiLogicSAS

# 仮想マシン設定変更用オブジェクト定義
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

# USBコントローラの追加
# これがないとWindows環境でマウスが動かない
# https://communities.vmware.com/t5/VMware-PowerCLI-Discussions/Where-is-the-quot-Get-USBController-quot-cmdlet-Same-with-Remove/td-p/2155582
# 上記だとUSB 2.0コントローラ追加
$newSpec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$newSpec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$newSpec.deviceChange[0].operation = "add"
#$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBController # USB2.0コントローラ
$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBXHCIController # USB3.0コントローラ

# EFIかBIOSか
# https://docs.vmware.com/jp/VMware-Cloud-on-AWS/services/com.vmware.vsphere.vmc-aws-manage-vms.doc/GUID-898217D4-689D-4EB5-866C-888353FE241C.html
#https://github.com/vmware/PowerCLI-Example-Scripts/blob/master/Scripts/SecureBoot.ps1
# BIOSを設定する場合は、SecureBootをdisableにする必要がある
#$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
# 仮想マシン起動オプション変更用オブジェクト定義
$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
#$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::efi
#$bootOptions.EfiSecureBootEnabled = $true
$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::bios
$bootOptions.EfiSecureBootEnabled = $false
$newSpec.BootOptions=$bootOptions


# 仮想マシンへの設定反映
#(get-view $vm).ReconfigVM_Task($newSpec)
$vm.ExtensionData.ReconfigVM($newSpec)


# 接続切断
Disconnect-VIServer -Server $vcenterserver -Confirm:$false

解説

仮想マシンにハードディスクを追加する

仮想マシンに新しく空っぽのハードディスクを追加する場合は、「New-HardDisk -VM 仮想マシン ~」で指定するが、Copy-HardDiskでコピーしてきたハードディスクを登録する場合が分かりづらかった。

結果としては、新規と同じく「New-HardDisk -VM 仮想マシン ~」でよかった。

今回の場合は、CopyHardDiskを実行した結果を変数にいれて、それをNew-HardDIskで登録、という形にした。

$adddiskinfo=Copy-HardDisk -Harddisk $sourcevmdk -DestinationPath $targetvmdk -DestinationStorageFormat Thin

$vm = get-Vm $vmname
New-HardDisk -VM $vm -DiskPath $adddiskinfo.Filename

仮想マシンハードウェアにUSB 3.0コントローラを追加する

Host Clientから作成した場合は、USB 3.0コントローラが作成されていたが、New-VMコマンドでは作成されなかった。このため、Windowsが起動した後にUSBマウスが存在できず、マウス操作ができなかった。(キーボードはPS/2キーボード扱いとして使えたようだった)

このUSB 3.0コントローラを追加するための操作がわからず、いろいろ調べたところ「Where is the “Get-USBController” cmdlet? (Same with Remove- and New-)」の記述を見て、USB 2.0コントローラの追加手法が分かった。

その後、VirtualUSBController を起点に調べることで、 xHCIはVirtualUSBXHCIControllerという名前であることがわかり、解決した

$vm=Get-VM -Name 仮想マシン名
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$newSpec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$newSpec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$newSpec.deviceChange[0].operation = "add"
#$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBController # USB2.0コントローラ
$newSpec.deviceChange[0].device = New-Object VMware.Vim.VirtualUSBXHCIController # USB3.0コントローラ

# 仮想マシンへの設定反映
#(get-view $vm).ReconfigVM_Task($newSpec)
$vm.ExtensionData.ReconfigVM($newSpec)

設定を反映する部分は、ネタ元では「Get-View」を使っていたが、後述のSecureBootについての結果ではGet-VM経由で実施しているスクリプトがあったので、それを使用している。

BIOS/EFI切り替え

仮想マシンをBIOS起動にするか、EFI起動にするかを設定する手法。

2021現在のPowerCLIでNew-VMした時のデフォルトはEFI起動でセキュアブート有効になっている。

これをBIOS起動に設定する場合は、セキュアブートを無効にしてからBIOSに切り替える必要があるので下記にようになる。

$vm=Get-VM -Name 仮想マシン名
$newSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.EfiSecureBootEnabled = $false
$newSpec.BootOptions=$bootOptions

$newSpec.Firmware = [VMware.Vim.GuestOsDescriptorFirmwareType]::bios

$vm.ExtensionData.ReconfigVM($newSpec)



OVAファイルをOVFに変換する


NetAppシミュレータの古いバージョンは圧縮ありのOVAファイルで提供されている。

これをvSphere 7.0環境で使おうとすると、圧縮されているので使えない、と拒否される。

変換ツールを使ってもよいのだが、手動でも変換できる

OVAファイルは中にovfファイルとvmdkファイルが入っているだけのtarファイルなので、7zipなどのツールを使って展開できる。

vsphere 7.0ではvmdk.gzは使えないので、これも展開する

OVFファイルの中身はXMLファイルとなっていて、元の中身は、vmdk.gzのファイルを指定している。

これを展開後のファイル名とファイルサイズに置き換える

また「ovf:compression=”gzip”」という記述も削除する

こうやって出来たOVFファイルとVMDKファイルを複数指定してvSphereで読み込ませる。

読み込ませる下記の様な形で「5ファイル」という表示になる

記述に問題なければOVFテンプレートのデプロイが継続できる。