Cisco UCSのCIMCにssh接続して設定を行う

Cisco UCSのCisco Integrated Management Controller (CIMC)はWeb管理画面とssh接続によるCLI管理がある。

CIMCについているホスト名は基本的に「サーバ機種名-シリアル番号」となっている。

ホスト名を確認する操作をCLIから行うには、scope:cimc/network以下でdetailを表示する操作になる。

ホスト名# scope cimc/network
ホスト名 /cimc/network # show detail
Network Setting:
    IPv4 Enabled: yes
    IPv4 Address: xxx.xxx.xxx.xxx
    IPv4 Netmask: 255.255.255.0
    IPv4 Gateway: xxx.xxx.xxx.xxx
    DHCP Enabled: no
    DDNS Enabled: yes
    DDNS Update Domain:
    DDNS Refresh Interval(0-8736 Hr): 0
    Obtain DNS Server by DHCP: no
    Preferred DNS: xxx.xxx.xxx.xxx
    Alternate DNS: 0.0.0.0
    IPv6 Enabled: yes
    IPv6 Address: ::
    IPv6 Prefix: 64
    IPv6 Gateway: ::
    IPv6 Link Local: fe80::86b8:xxxx:xxxx:xxxx
    IPv6 SLAAC Address: ::
    IPV6 DHCP Enabled: yes
    IPV6 Obtain DNS Server by DHCP: yes
    IPV6 Preferred DNS: ::
    IPV6 Alternate DNS: ::
    VLAN Enabled: no
    VLAN ID: 1
    VLAN Priority: 0
    Port Profile:
    Hostname: ホスト名
    MAC Address: XX:XX:XX:XX:XX:XX
    NIC Mode: dedicated
    NIC Redundancy: none
    VIC Slot: riser1
    Auto Negotiate: yes
    Admin Network Speed: auto
    Admin Duplex: auto
    Operational Network Speed: 1Gbps
    Operational Duplex: full
ホスト名 /cimc/network #

show detailだといろんな項目が表示されすぎるので、ホスト名だけを取り出すことができないか調べたところ「| grep キーワード」が使えた。

ホスト名 /cimc/network # show detail | grep Hostname
    Hostname: ホスト名
ホスト名 /cimc/network #

ホスト名変更操作は scope:cimc/network にて set hostnameを実行したあと、commitで確定する。

ホスト名 /cimc/network # set hostname 新ホスト名
Create new certificate with CN as new hostname? [y|N] y

ホスト名 /cimc/network *# commit
Changes to the network settings will be applied immediately.
You may lose connectivity to the Cisco IMC and may have to log in again.
Do you wish to continue? [y/N] y

注意点として、ホスト名変更に伴い、Web管理GUIおよびssh接続で使用するSSL証明書で使用するCN(common name)が変更されるため証明書が作成されるということがある。

また、再作成に伴いCIMC自体も再起動されるため、commit後、再起動完了までの数分間CIMCに接続できなくなる。

このため、CIMCホスト名変更処理を行ったあとは、再起動待ちと証明書再発行にともなうssh接続時のキー変更に対応する処理を入れる必要がある。

ssh接続時のknown_hostsファイルから該当するエントリを削除したい場合は、 ssh-keygenコマンドの-Rオプションを使うことで行える。

osakanataro@ubuntu2004:~/imc$ ssh-keygen -R xxx.xxx.xxx.xxx
# Host xxx.xxx.xxx.xxx found: line 1
/home/osakanataro/.ssh/known_hosts updated.
Original contents retained as /home/osakanataro/.ssh/known_hosts.old
osakanataro@ubuntu2004:~/imc$

これで材料が揃ったので、スクリプトを作成する。

最初は Ciscoのcimc-ansible , cimcsdk を使用できないか検討したのですが、どちらもCIMCのホスト名変更に関する処理が実装されていないようだったので、expectコマンドによる処理を採用しました。

作成するにあたり下記を参考にしています。
How to programmatically enable redfish on Cisco CIMC?
Automate the UCS CLI with expect

今回作成したスクリプトは下記の様になりました。

#!/usr/bin/expect -f

# CIMCへの接続に時間がかかるようで
# 標準設定のtimeout値だとコマンド実行前にプロセスが進んでしまう 
# -1 を設定すると応答があるまで待つが
# ホスト名変更処理後は再起動がかかり、-1だと再起動が終わるまで待つことになってしまい時間がかかるので20に設定
set timeout 20

set CIMCaddr "xxx.xxx.xxx.xxx"
set CIMCuser "admin"
set CIMCpass "パスワード"
set CIMChostname "新ホスト名"


spawn ssh -l $CIMCuser -t $CIMCaddr
expect_after eof {exit 1}
# ログイン処理
expect {
        "*?assword:*" {
                send -- "$CIMCpass\r"
        }
        "(yes/no*)*" {
                send -- "yes\r"
                expect "*?assword:*"
                send -- "$CIMCpass\r"
        }
	# ホスト名変更時にssl証明書再作成が行われるため
	# キーが変わることに対する対応
	# リトライ処理が面倒だったので、古いキーを削除するところまでしか行わない
	# 必要に応じて手動で再実行で対応
        "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" {
                system ssh-keygen -R $CIMCaddr
                puts "\nplease re-exec this script\n"
                exit 2
        }
}

expect "# "
send -- "scope cimc/network\r"
expect "# "

# 現在のホスト名確認
send -- "show detail | grep Hostname \r"
expect -indices -re "Hostname: (.*)\r"
# 文字列検出に使った": "の2文字分を足す
set strst [string last ": " $expect_out(buffer)]
set strst [expr $strst + 2]
# 行の終わりの改行分を引く
set stred [string length $expect_out(buffer)]
set stred [expr $stred - 2]
set hostnamenow [string range $expect_out(buffer) $strst $stred]
puts "CIMChostname: $CIMChostname"
puts "hostname: $hostnamenow"

# ホスト名の変更が必要か?
if { "$CIMChostname" != "$hostnamenow" } {
        puts "change hostname"
} else {
        puts "no change"
        expect "# "
        send -- "top\r"
        expect "# "
        send -- "exit\r"
        exit 0
}

# ホスト名変更
expect "# "
send -- "set hostname $CIMChostname\r"
expect "*new hostname?*"
send -- "y\r"
expect "# "
send -- "show detail | grep Hostname \r"
expect "# "
send -- "commit\r"
expect "*\[y/N] "
send -- "y\r"

# ホスト名確認
#  ただし実際には再起動が掛かっているので実行できない
expect "# "
send -- "show detail | grep Hostname \r"

expect "# "
send -- "top\r"
expect "# "
send -- "exit\r"

exit 0

expectでスクリプトを作った時のメモ書き

ssh経由の操作をexpectコマンドで自動化しようとした時に、expectで調べると、入出力関連に関しては出てくるが、文字列操作や制御構文周りがよくわからない。

ここら辺は、tclに関して調べるとわかるようになっている。

参考にしたサイト

LInux JM Home Page「expect (1)
FreeSoftNet 「Tcl>文法とコマンド
アプリコット PukiWiki「expectで自動化

if文の書き方

他の言語と同じように「if (条件){実行内容}」と書くと妙なエラーになる。

expectでは「if {条件} {実行内容}」というように、どちらも「{}」で囲む。
また、「if」と「{」の間、「条件の}」と「実行内容の{」の間のそれぞれにスペースを挟む必要がある。

文字列を比較して、異なる場合は「diff」、同じであれば「same」と出力するexpectは下記の様になる。

#!/usr/bin/expect -f
set hostnamenew "testhostnew"
set hostnamenow "testhost"

puts "hostnamenew: $hostnamenew"
puts "hostnamenow: $hostnamenow"

if { "$hostnamenew" != "$hostnamenow" } {
        puts "diff"
} else {
        puts "same"
}

誤って「if (条件) {実行内容}」とした場合、下記の様な「unbalanced open paren in expression」というエラーとなる。

unbalanced open paren
in expression "("
    (parsing expression "(")
    invoked from within
"if ( "$hostnamenew" != "$hostnamenow" ) {
        puts "diff"
} else {
        puts "same"
}"

「if(条件) {実行内容}」と「if{条件} {実行内容}」とifと{の間にスペースを入れない場合は下記のような「invalid command name」となる

invalid command name "if("
    while executing
"if( "$hostnamenew" != "$hostnamenow" ){"
invalid command name "if{"
    while executing
"if{ "$hostnamenew" != "$hostnamenow" }{"

面倒くさいことに「if {条件}{実行内容}」と、ifと条件の間にはスペース入れたけど、条件と実行内容の間にスペースがない場合は下記の「extra characters after close-brace while executing」というエラーになる。

extra characters after close-brace
    while executing
"if { "$hostnamenew" != "$hostnamenow" }{"

コマンド出力から文字列を取り出しと文字列の切り出し

expectを使う場合は、sshで他のホストに接続してコマンドを実行する、という用途で使うことが多い。

コマンドの実行結果によって、処理を変えたい場合、どうすればいいのか?

「expect -indices -re “条件式”」で条件式に該当した行を$expect_out(数字,string)で拾うみたいなんだけど、いまいち動作がよくわからない。

「ip a s ens160」を実行して、そのIPアドレスを取得したい場合の例として以下を作った

expect "\[#$] "
send -- "ip a s ens160\r"
expect -indices -re "inet (.*)\r"
puts "===buffer==="
puts "$expect_out(buffer)"
puts "===str0==="
puts "$expect_out(0,string)"
puts "===str1==="
puts "$expect_out(1,string)"
puts "===="

これの実行結果は下記となった。

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:33:27:f8 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
===buffer===
ip a s ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:33:27:f8 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
===str0===
inet 172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
===str1===
172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
====
       valid_lft forever preferred_lft forever
    inet6 fe80::cca7:388a:36e7:d688/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

条件を「inet (.*)\r」から「inet6 (.*)\r」に変更

2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:33:27:f8 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::cca7:388a:36e7:d688/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
===buffer===
ip a s ens160
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:33:27:f8 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 172.17.44.48/16 brd 172.17.255.255 scope global noprefixroute ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::cca7:388a:36e7:d688/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
===str0===
inet6 fe80::cca7:388a:36e7:d688/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
===str1===
fe80::cca7:388a:36e7:d688/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
====

ここからさらにIPアドレスの部分を取り出すには「string first ~」「string last ~」と「string range ~」を使って文字列を切り出す。

set str $expect_out(1,string)
set stred [string first "/" $str]
puts "[string range $str 0 $stred]"
set stred [expr $stred - 1]
puts "[string range $str 0 $stred]"

上記の実行結果としては下記のようになる。

172.17.44.48/
172.17.44.48

他の言語のsubstring系だと開始アドレスと、そこを起点に取り出す文字列の長さを指定するが、tclのstring range では、開始アドレスと終了アドレスの2つを指定する形になるので注意が必要になる。

リストファイルを順に処理する

サーバ名 IPアドレス ユーザ名 パスワードがかかれている一覧ファイルを読み込ませて順に処理させる例

まず、一覧ファイルの例

server1       172.17.44.51    admin   password123#
server2       172.17.44.52    admin   password123#

スクリプト

#!/usr/bin/expect -f

if { $argc < 1 } {
        puts "Usage: $argv0 <serverlist>"
        exit 1
}

set filename [lindex $argv 0]

set contents [read [open $filename]]
set contentline [split $contents "\n"]
foreach line $contentline {
        #puts "$line"
        set linesplit [split $line "\t"]
        set hostname [lindex $linesplit 0]
        set ipaddr [lindex $linesplit 1]
        set username [lindex $linesplit 2]
        set password [lindex $linesplit 3]
        if { $hostname != "" } {
                puts "hostname:$hostname, ipaddr:$ipaddr, username:$username, password:$password"
        }
}

実行例

$ ./sample3 serverlist
hostname:server1, ipaddr:172.17.44.51, username:admin, password:password123#
hostname:server2, ipaddr:172.17.44.52, username:admin, password:password123#
$

なお、処理スクリプトに「if { $hostname != “” } {」を入れているのは改行のみやEOFのみの行を処理してしまわないようにするため

とはいえ、これを応用してssh接続させるスクリプトにしたところ、間にアクセスできないホストがあると、そこでエラー終了してしまうので、取り扱いが面倒であることが判明。
(エラー時の処理を実装すればいいんだけど、面倒)

よって、bashスクリプト側でリストは処理し、そこからexpectスクリプトを呼び出すこととなった。

そうやって作成したのが「Cisco UCSのCIMCにssh接続して設定を行う」になる

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のみ環境で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)



Ubuntu 18.04以降/CentOS7向けにMicrosoftがOpenJDK 11のパッケージ配布を始めた

Microsoftは従来からLinuxのいくつかのディストリビューション向けにバイナリパッケージを配布するレポジトリサーバ https://packages.microsoft.com/ を公開している。

たとえば、PowerShellを使いたい場合は「Linux への PowerShell のインストール」の手順を行って設定していた。

このたび、MicrosoftからOpenJDK 11のプレビュー版提供が開始された。「Announcing Preview of Microsoft Build of OpenJDK

Microsoft Build of OpenJDK」を見ると「Linux Installers for OpenJDK 11」という手順が公開されており、これを見ると、Debian 9と10、Ubuntu 18.04以降、CentOS8で従来から提供されているMicrosoftプロダクトレポジトリにおいて、msopenjdk-11の提供が始まったように見える。

うちのCentOS7環境はPowerShellを使える様にしているので使えるはず!と「yum search msopenjdk」を実行してみると見付からない・・・

設定されているレポジトリファイルはPowerShell手順にあるようにRHEL7のものだしなぁ・・・

# curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

・・・OpenJDKの方のCentOS7手順を見てみる。

# sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm

取得しているディレクトリが https://packages.microsoft.com/config/rhel/7/ ではなく https://packages.microsoft.com/config/centos/7/ に変更されている。

というわけで、レポジトリファイルを変更して再実行!

無事検索されるようになりました。

が・・・よく見ると、CentOS7レポジトリでは「powershell」はなく「powershell-preview」というパッケージのみ提供な模様。(rhel7ではpowershell,powershell-lts,powershell-previewが提供されている)

CetnOS7ユーザは注意が必要なようです。

とはいえRHEL7/CentOS7ユーザはRedHat提供のOpenJDK 11が使えますけどね・・・(java-11-openjdk)。「OpenJDK RPMs for RHEL 7」「第2章 RED HAT ENTERPRISE LINUX での OPENJDK 11 のインストール

RHEL8/CentOS8についても同様で、OpenJDK 11をjava-11-openjdkというパッケージ名で提供しており、また、java-latest-openjdkでOpenJDK 16も提供しているので除外されているようですね。