cjnotes – cjnotes is a personal Blog about virtualization maintained by CJ

ESXi 6系で、起動時間が一番早いバージョンは？

CJです。

約半年前にリリース(2018.4.7)された vSphere 6.7 には、”Quick Boot” という新たな機能が追加されたこと、知っていますか？

今日は “Quick Boot” 機能をみて、ふっと純粋に以下の疑問が沸いたので検証してみた結果を共有したいと思います。

その疑問は、”ESXiの各バージョンごとに、起動時間の違いはあるだろうか？”

その前に、まずは Quick Boot について簡単に紹介させてください。

vSphere 6.7 新機能： Quck Boot

vSphere 6.7 improves efficiency at scale when updating ESXi hosts, significantly reducing maintenance time by eliminating one of two reboots normally required for major version upgrades (Single Reboot). In addition to that, vSphere Quick Boot is a new innovation that restarts the ESXi hypervisor without rebooting the physical host, skipping time-consuming hardware initialization.

上記、VMware vSphere Blog からの引用となりますが、

要は物理ホストの再起動をせず、ESXi を再起動させる機能となります。

ハードウェアの初期化が省略されるため、ESXiのバージョンアップなどのメンテナンス時間が短縮される効果があります。ちなみに、本機能はサポートされるハードウェアのみに活用できるようです。 ESXi 側で以下のコマンドにて、サポートされているかどうかの確認ができます。

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

特にインフラ管理者には嬉しい機能かと思うので、ぜひお試しください。

検証構成

・比較対象の各ESXi は vSAN上の Nested 環境で用意してあります。

・各ESXi は同一物理ホスト上で動いてあります。

・各ESXiのスペックは、2Core、4GB ram で同一。

・各 ESXi のバージョンは、以下の通りです。

バージョン	Build	ESXi名
6.0U3	5572656	esxi09
6.5U1	5969303	esxi08
6.5U2	8294253	esxi07
6.7U1	10302608	esxi06

測定内容

・測定1 : ESXi が停止状態から起動完了までの “起動時間 (秒)”

・測定2 : ESXi が起動状態から再起動完了までの “再起動時間 (秒)”

測定方法

・測定1 : ESXi コンソール画面上で、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

・測定2 : ESXi コンソールの再起動直前の画面から、F11により再起動を開始して、ESXi ホスト名が表示される画面に繊維されたタイミングまでの時間をストップウェッチにて計測。

測定結果

測定1 : なんと 6.0U3 のほうが、一番早かったです。

測定2 : 再起動は 6.7U1 のほうが、一番早かったです。

6.0U3 と 6.7U1 間には、微妙な誤差がありそうですが、6.5系と6.7U1間には差ほど大きいな違いはないようですね。数秒の差とはいえ、メンテナンスの際には規模によってこれも短縮したくなるのではないでしょうか。

[参考情報]

ESXi Hardware Requirements
https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html

Quick Boot Compatibility
https://kb.vmware.com/s/article/52477

Introducing VMware vSphere 6.7!
https://blogs.vmware.com/vsphere/2018/04/introducing-vmware-vsphere-6-7.html

ESXi に残っている vSAN情報を削除するには？

CJです。

vSANクラスター配下で動いている ESXi ホストを、クラスター外に持ち出すケース(クラスター内のホストを別環境に転用したい場合など)があると思います。

今日はその際に使える簡単な Tipを紹介したいと思います。

vSANクラスターから ESXi ホストを外す流れ

１．対象ESXi ホストをメンテナンスモードに切り替え

２．対象ESXi の DiskGroup を削除

3. Drag&Drop にて、対象 ESXi ホストを vSANクラスター外に移動

基本はこれだけでよいはずですが、問題は次の事象です。

対象 ESXi 上での操作 (SSH接続)

以下のコマンドにて、vSAN情報が残っていないかを確認。

esxcli vsan storage list

この結果で、vSAN Disk情報が表示された場合は、以下のコマンドにて Disk情報を削除。

esxcli vsan storage remove -u [DISKGROUPのUUID]

もし、vSAN Disk情報など何も表示されてはいないが、vSAN情報が残っていることで別のクラスター環境へ移動ができない場合は、”vdq -q” と “esxcli vsan cluster get” コマンドにて状況を確認。

vdq -q
[
{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Eligible for use by VSAN”,
“Reason” : “None”,
“IsSSD” : “1”,
“IsCapacityFlash”: “1”,
“IsPDL” : “0”,
},{
“Name” : “naa.600605XXXXXXXXXX2270bcXXXXXXXXXX”,
“VSANUUID” : “”,
“State” : “Ineligible for use by VSAN”,
“Reason” : “Has partitions”,
“IsSSD” : “0”,
“IsCapacityFlash”: “0”,
“IsPDL” : “0”,
},esxcli vsan cluster getCluster Information
Enabled: true
Current Local Time: 2018-11-05T09:33:53Z
Local Node UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 52dc722d-a2c0-XXXX-XXXX-XXXXXXXXXX85
Sub-Cluster Membership Entry Revision: 5
Sub-Cluster Member Count: 1
Sub-Cluster Member UUIDs: 5afe36c2-e2a1-XXXX-XXXX-XXXXXXXXXX20
Sub-Cluster Membership UUID: 1a9c835b-dd2f-XXXX-XXXX-XXXXXXXXXX20
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: a2a65e3c-33ed-XXXX-XXXX-XXXXXXXXXXf2 8 2018-11-05T09:15:51.659

これで vSAN情報が残っていることがわかりました。

では、早速次のコマンドにて、vSAN情報を削除しましょう。

esxcli vsan cluster leave

これで削除が完了しました。

もう一度、vSANクラスター情報を確認してみると、以下の通りに削除されていることがわかります。

esxcli vsan cluster get
vSAN Clustering is not enabled on this host

上記コマンドは、vSphere 6.5U1 環境での動作確認済みのものとなります。

vSphere バージョンによっては、コマンドが変更されている可能性があります。

その際は、”-?” にて Help 情報を参照してください。

vSphere 6.5以降の環境から仮想マシンを OVAでエクスポートするには？

CJです。

いまさら感がありますが、vSphere 6.5 からは仮想マシンをエクスポートする際に “OVF”のみがサポートされるようになっているようです。

vSphere6.0 までは、vSphere Client が使えて、仮想マシンをエクスポートする際に OVF or OVA どちらかのファイル形式が選択可能でした。これが、vSphere 6.5 からは vSphere Web Client のみをサポートすることになり、統合プラグイン関係で OVFのみをサポートする形に変わったようです。

とはいえ、やはりファイル1個で使いやすかった OVA は継続的に使いたいですし、移行先のクラウドが OVA のみ対応しているのあれば、なおさらです。

このような状況を踏まえ、vSphere6.5 以降の環境で動いている仮想マシンを OVA にエクスポートしたい方向けにその方法を共有したいと思います。

vSphere 6.5環境で動いている仮想マシンを oVA にするには？

早速ですが、その方法は以下のように、一度 OVFでエクスポートし、それを ovftool を使って OVA に変換することです。

事前準備

ovftool インストールを踏み台サーバーにインストールが必要です。

ここでは、踏み台サーバーとして Windows を例とします。 Linux または Mac OS X も各自の環境に合わせて適切なパッケージを使えば、使用可能です。

１．OVF Tool Documentation ページへ移動して、最新バージョンをダウンロード

２．ダウンロードしたインストーラーを実行して、インストール完了。

３．環境変数に PATH を登録する (手順は割愛します)と便利。

OVFエクスポート

vSphere Web Client から “仮想マシン > テンプレート > OVF 。。。”　メニューからエクスポートを実施。ここでひとつTipとして、OVFエクスポートは HTML5版の vSphere Web Client を使用するのをお勧めします。フラッシュ版の場合、エクスポートのステータスや表示が正常に表示されないケースがあります。

OVAへの変換

OVFファイルの場所例： D:\CJ\powercli\ovftool\ovf\vcsa01_cj-lab.com.[ovf, mf, vmdk]

OVAファイルの変換先例： D:\CJ\powercli\ovftool\ova\vcsa01_cj-lab.com.ova

以下のコマンドを実行する。

>ovftool ./vcsa01_cj-lab.com.ovf ../ova/vcsa01_cj-lab.com.ova

すると、以下のようにコンバートが行われます。

最後に、”Completed successfully” メッセージが表示されれば、完了です。

いかがですか、とても簡単ではありませんか。

個人的にも OVAサポートは継続してほしいところですが、そこは vmwareさんに改善を期待しながら、今現時点ではこのような対策を活用いただければ嬉しいです。

[参考情報]

OVF Tool Documentation

https://www.vmware.com/support/developer/ovf/

写真でみる vmworld 2018 US

CJです。

先週たくさんのトピックが取り上げられた vmworld 2018 US ですが、技術的なトピック外のイベント会場雰囲気を簡単ながら写真にて共有したいと思います。

1.出発

2.初日、会場へ

3.登録 (参加証の発行)

4.参加証

5.SOLUTIONS EXCHANGE

この中に各様々なベンダーの展示会があり、VMVILLAGEがあります。

6.VMVILLAGE

多くの参加者が立ち寄る写真スポットです。

7.VMVILLAGEの休憩所

8.PARTNER LOUNGE

9.EDUCATION AND CERTIFICATION LOUNGE

10.VMVILLAGE内のBROADCASTBOOTH

11.VMTN AND VMWARE {code}

12.VMUG LOUNGE

13.VMWARE INNOVATION ZONE

INNOVATION ZONEの写真を撮ろうしたら、ブースの方と目があって、ポーズ取ってと話したら笑顔でハッピーなポーズを取ってくれました。どうも～

14.Drone Racing & Virtual Basketball

このようなちょっとしたゲームも楽しめるのがいくつかあります。

15.MEALS

大事な食事(左)と、1日2回(午前と午後)出される飲み物です。

食事にももちろんコーヒーやアイスティーなどもおいてあります。

16.VMworld FEST

最終日(夜)には、ほとんどのイベントが終わり、フェースが開かれます。

たくさんの参加者と会って話したり、ゲームしたり、踊ったりすることができます。

以上、簡単ながらの “写真でみる会場と雰囲気の共有” でした。

vmworld 2018 バルセロナまたは vmworld 2019 (来年はサンフランシスコ開催となります。) への参加をご検討の方に少し約に立てればと思います。

vmworld 2018 US : 参加の事前準備

CJです。

来週から、アメリカのラスベガスで “vmworld 2018 US” が開催されますが、自分も 2年ぶりに参加する予定です。

2年ぶりだと、登録方法も忘れがちなのでまとめながら、普段のTech記事だけでなく、このようなイベント情報についてもシェアしたいと思います。

では、早速イベントの登録方法から見ていきましょう。

１．vmworld イベント登録

vmworld 公式ページにアクセスして、”Register Now” ボタンから登録を開始すればOKです。#vmworldアカウント作成から開始～

Tip１

イベント開始約3ヶ月前から登録が可能になります。早めに登録すると “早期割引”が適用されて、一般人枠であれば 200 USD (例. Alumi枠)ほど節約できます。過去参加4回のイベント中、2回以上本イベントに参加されている方はこの Alumi枠が適用されます。

Tip2

もし、VMware社とパートナー関係である場合、登録時に “VMware Partner ID ” 入力欄が表示されので、Partner IDを入力してください。これにより、パートナー限定のセッションなどに参加することができるようになります。

２．ESTA登録も忘れず

やはり、入国関連の手続きは早く済ませておいた方が良いです。忘れず～

また、申請後の結果の確認も忘れず～事前に確認しておくことをお勧めします。

３．セッション登録

イベントから約1ヵ月半くらい前から登録が開始となります。(今年は、7月中旬からセッション登録が開始されました。) 興味あるセッションを登録していきましょう。

Tip3

たくさんのセッションがあるため、登録前にカタログ上である程度内容が確認できるので、事前に興味あるセッションをチェックしておきましょう。

セッション登録のはじめは、まず “General Session / Partner General Session”からをお勧めします。VMware社のビジョン・戦略・方針をはじめ、署名 Guest Speaker のお話を生で聞くことができます。

人気セッション (vSphere、vSAN、NSXなど)の場合は、すぐ満員になりますので早めに登録するのがベターですが、開始して間もないところで登録できなかった場合でも諦めず、一旦 “Wait List” でも登録しておきましょう。VMware社もどのセッションにどれくらいの人が集まるかわからないはずです。(ある程度予測はできるものの) 一旦登録しておけば、後の会場の変更などを行いつつ参加可能の人数枠を増やすケースがあるようです。(Wait Listからいつの間にか Scheduled状態に変わります。)

４．現地のイベント情報もチェック・登録

vmworldに参加する各会社が主催するイベントはもちろん、vmwareが主催するパートナー関連イベント、vExpert向けのイベント、VMware User Group(VMUG)向けのイベントなど、たくさんのイベントが開催されます。世界各地から集まるユーザー達と交流しながら、色々なお話ができる良い機会ですので、ぜひ活用してください。(結構、時間がバッティングするこも多いので、各自のスケジュールをを要調整) また、このような情報は検索エンジンやSNSなどから入手できるため、興味あるイベントには事前に登録しておくことをお勧めします。

#RUN DMC、The Roots、Snoop Dogg などパフォーマーがすごいですね。。

５．vmworld アプリのインストール

Android, iPhoneなどの事前に vmworld用アプリを入れておきましょう。

アップストアで公開されるのは、イベント開始前の約2週間前となります。

自分が登録したセッションのスケジュールはもちろん、会場、無料wifi情報、各イベント情報も確認できるなどとても便利です。セッション聞きながらメモを取ってそれをメールに飛ばせるようにもなっているため、イベントのマストアイテムです。

以上、簡単ながら事前準備編をシェアさせていただきました。

次回は、現地の情報・雰囲気もシェアできればと思います。

CentOS7に PowerCLI をインストールするには？

CJです。

vSphere 環境をより柔軟に管理するには、PowerCLIが必要かと思います。

この PowerCLI、実は Linux 上でも使えること知っていますか？

使えるんです。PowerCLI Coreという形で Linuxでも使用可能な状態で配布されましたが、以下のように PowerCLI 10.0 からは Coreという形はなくなり、PowerCLIに統合された形での配布となっています。

PowerCLI Core has been officially released as part of PowerCLI 10.0. This Fling is no longer under development and future multi-platform support will be a part of PowerCLI 10.0.

今回は、CentOS7上で PowerCLI をインストールする方法について共有したいと思います。

STEP1. まず、PowerShell をインストール (on CentOS7)

以下のように、マイクロソフトのリポジトリを登録。

# vi /etc/yum.repos.d/microsoft.repo

[packages-microsoft-com-prod]
name=packages-microsoft-com-prod
baseurl=https://packages.microsoft.com/rhel/7/prod/
enabled=1
gpgcheck=1
gpgkey=https://packages.microsoft.com/keys/microsoft.asc

1-1. 安定版をインスールする方法。(お勧め)

この後は、普通に yum で PowerShell をインストール。

# yum install powershell

1-2. 最新版をインスールする方法。

以下のサイトより、自分の環境に合うバージョンをダウンロードしてインストール。(ここの手順は省略)

https://github.com/PowerShell/PowerShell/releases

インストールが完了したら、powershell 起動。

# pwsh
PowerShell v6.1.0-preview.2
Copyright (c) Microsoft Corporation. All rights reserved.https://aka.ms/pscore6-docs
Type ‘help’ to get help.
PS /root>

STEP2. 続いて、PowerCLI をインストール (on CentOS7)

PS /root> Install-Module -Name VMware.PowerCLI
PS /root> Get-Module -ListAvailable
PS /root> Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

STEP3. 最後に、vCenterへのアクセスを試す (on CentOS7)

PS /root> Connect-VIServer -server [vCenter名 or IPアドレス]

Linux のログサーバーから vCenterのイベントログなどを収集したいケースなどあると思いますが、ぜひ必要に応じて Linux 上でも PowerCLIが動くことを覚えてお試しいただければと思います。

[参考情報]

https://github.com/PowerShell/PowerShell/releases

Installing VMware PowerCLI 10.0.0 on Linux

https://virtualizationreview.com/articles/2017/06/01/how-to-install-and-use-powershell-and-powercli-on-linux.aspx

On-Disk フォーマット更新時のサービス影響は？

CJです。

vSphere 5.5の End of General Support (2018/09/19) が近づいていることもあり、このタイミングでの移行やそれに伴うバージョンアップを検討されるケースは多くあるのではないでしょうか。特にバージョンアップの際に実際仮想マシンへの影響度合いも気になるかと思います。

今回は、vSAN基盤のバージョンアップ (ESXi 6.0U3 → 6.5U1) を行う中で、On-Disk フォーマットというプロセスが発生します。Diskに関するところでサービス (仮想マシンの通信)影響が発生するか否かについて共有したいと思います。

ちなみに、On-Disk フォーマットについてはこちらを参照してください。

テストイメージ図

上記のように、同一の vSAN環境 (vsanDatastore) 上で稼動している仮想マシン(CJ01、CJ02)間の疎通 (ping) を行いつつ、On-Diskフォーマットを更新して結果を確認したいと思います。

vSAN設定画面 (更新前)

vCenter > vSAN Cluster > 設定 > vSAN > 全般 > オンディスクフォーマットのバージョン

こちらの画面で “アップグレードの事前チェック” ボタンをクリックする、vSAN内部で更新ができるかどうかをチェックしてくれます。

アップグレード

事前チェックが正常に完了した後、”アップグレード” ボタンをクリック。すると、

アップグレード開始確認画面が表示されるので、”はい” で次へ。

※冗長性の低下を許可を選択すると、更新がなんらかの理由で失敗した場合にデーター損失につながる可能性がありますので、各自の環境に合わせて注意してお使いいただければと思います。

進行内容は以下の通りとなります。

0 ～ 5%：クラスタのチェック。
5 ～ 10%：ディスクグループのアップグレード。
10 ～ 15%：オブジェクトの再編成。
15 ～ 95%：ディスクグループの削除および再フォーマット。
95～100%：最終的なオブジェクトバージョンのアップグレード。

vSAN設定画面 (更新後)

ご覧のように、ディスクフォーマットのバージョンが更新 (3.0 → 5.0) されていることがわかります。

サービス(通信)影響は？

パケットロスゼロのサービス(通信)影響はありませんでした。

vSAN基盤を更新する上で、忘れがちなところでもある On-Diskフォーマットですが既存フォーマットの違いを理解した上で必要に応じて忘れず更新いただければと思います。

TIP (RVC : 更新ステータス確認方法)

vsan.upgrade_status /localhost/[DATACENTER]/computers/[CLUSTER]

RVCにログイン上、上記コマンドにて更新ステータスが確認できます。

vsan.upgrade_status -r [秒] /localhost/[DATACENTER]/computers/[CLUSTER]

また、秒指定 (min 60秒) をすると、ユーザーが “Ctrl + c” で抜けない限り画面上更新情報を指定秒間出力してくれます。

運用上、ぜひRVCモードもご活用ください。

[参考情報]

vSAN ディスクフォーマットについて

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.virtualsan.doc/GUID-08728A9E-88E0-4CEB-9764-E828719DA927.html

Disk format change going from 6.x to vSAN 6.6?

Disk format change going from 6.x to vSAN 6.6?

vCenter 配下の VM数を把握するには？

CJです。

vSphere基盤を運用する上で、以下の内容について確認したことありませんか？

・Cluster 配下のホスト数

・Cluster 配下のVM数

・PowerOn のVM数

・PowerOff のVM数

そうです、このような内容は計画メンテナンスを行う上で、一度確認したことがあるかと思います。vSphere Web Client を通して GUI でみたり、VMリストをコピーしてメモ帳で行数を把握して VMの数を数えるなどいくつか簡単な方法がありますが、今回は PowerCLIを使った適切・簡単な方法を共有したいと思います。

PowerCLIを起動した後に、以下のコマンドにて現在 vCenter 配下に VMがどれだけあるかみてみましょう。

Get-VM

自分の環境には、上記のように合計 6台のVMが動いている状態です。

では、早速 vCenter 配下で Clusterごとの Host、PowerOn状態の VM の数も以下のコマンドにて確認してみましょう。

Get-Cluster | Select Name, @{N=”Host Count”; E={($_ | Get-VMHost).Count}}, @{N=”VM Count”; E={($_ | Get-VM | Where-Object {$_.PowerState -eq “PoweredOn”}).Count}}

ごらんのように、Clusterごとの Host数および VM数が確認できることがわかります。

PowerOff のVM数を確認するには、以下のコマンドを使います。

Get-Cluster | Select Name, @{N=”Host Count”; E={($_ | Get-VMHost).Count}}, @{N=”VM Count”; E={($_ | Get-VM | Where-Object {$_.PowerState -eq “PoweredOff”}).Count}}

get-vm コマンドで確認したように、自分のテスト環境においては稼働中のVM 6台のみが vCenter 配下にある状態です。本当に PowerOff のVM数も拾えるかどうかを確認するため、VM1台を停止します。

Stop-VM CJVM

VMが停止したので、再度 PowerOn / Off のVM数を確認してみましょう。

きちんと、電源状態に合わせた VMの数が確認できました。

ぜひ、計画メンテナンス時などでご活用ください。

[参照情報]

Powercli Script to measure the count of Host and its Vm’s in a each clusters

https://communities.vmware.com/thread/514432

PowerCLI Reference / PowerState – Enum
https://code.vmware.com/docs/5060/cmdlet-reference#/doc/PowerState.html

VCS to VCSA : Windows版 vCenter から仮想アプライアンス版 vCenterへの移行手順

CJです。

多く使われている Windows版 vCenter Server (以下、VCS)も次期 vSphereバージョンからはサポート外になるようです。現在、仮想アプライアンス版 vCenter Server (以下、VCSA)ではほとんどが VCSと変わらず使える状態ですが、マルチNICが正式サポートされていなかったり一部もの足りないところもあるのが現状です。しかし、いつか VCSAになること、ライセンス節約の観点からのメリットもあるので、各自の状況に合わせて移行をご検討いただければと思います。

今回は、この移行方法についてスクリーンショットとともに流れを共有したいと思います。

移行環境

VCS：Windows Server 2012 R2 / PSC組み込み / 別途 DBサーバー(SQL server)が存在 / vCenter 6.0 U2

VCSA: vCenter 6.5 U1

Client: Windows Server 2012 R2

移行イメージ図

移行手順

VCSAデプロイ手順

1.VCS上に、VCSA isoファイルより、”migration-assistant” フォルダをコピーし、VMware-Migration-Assistant アプリを実行する。

Tip: 移行前に、以下の内容を確認してください。

・DRS 無効化 / NTP 同期 / Default Gateway 設定 / もし、iptables 制御している方はそちらも要確認

2.Client PC (以下、Client) に、VCSAの isoファイルをマウントしてインストールファイルを実行。”CDROM : vcsa-ui-installer\win32\installer.exe”

3.移行を選択

4.VCSAのデプロイ / 次へ

5.エンドユーザー使用許諾契約書 / 同意にチェックを入れて次へ

6.VCSの情報を入力して、次へ

サムプリントの検証画面が表示されたら、”はい” をクリック

7.デプロイ先の ESXi or vCenter 情報を入力 (ここでは ESXi 情報を入力しています。)

証明書に関する警告画面が表示されたら、”はい” をクリック

8.VCSA名と root パスワード情報を入力して、次へ

9.各自の環境に適した VCSAのサイズを選択して、次へ

10.データストアを選択して、次へ

11.ネットワーク構成情報を入力して、次へ

12.設定内容の確認ページが表示されるので、確認後問題なければ “終了” ボタンをクリック。そうすると、初期化された後デプロイが開始されます。

13.デプロイが完了されたら、次は VCSAへ接続します。

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

ちなみに、デプロイされた VCSAのディスク構成はどうなっているでしょう。

小 (4 vCPU、16GB RAM)サイズでは、以下の構成となっていることがわかりました。

VCSA への移行手順

1.”Windows 上の vCenter Server インスタンスからの移行” を選択

2.上記手順 8 で設定した VCSAの root パスワードにてログイン

3.ステージ1が終わっている状態で、ステージ2になることを確認の上、次へ

4.VCSの情報を入力して、次へ

証明書に関する警告画面が表示されたら、”OK” をクリック

5.VCS上では、以下のように事前チェックが走っていることがわかります。

暫くすると、移行前チェックの結果が表示されます。

今回、VCS上では VMware Update Manager (以下、VUM)が使用中だったための警告が表示されていますが、スキップします。”閉じる”をクリック。

6.今回の移行では、設定のみ移行すればOKということで、次へ

7.CEIP 参加可否の画面が表示されますが、ここではチェックをOFFにして、次へ

8.設定の確認画面が表示されます。”ソースの vCenter Server をバックアップしました” のチェックボックスにチェックを入れて、終了。

シャットダウンの警告が表示されるので、”OK” をクリック。

VCSAは基本 VCSの情報を引き継ぐため、同一セグメントに置かれている VCSを起動前に止める動きとなっています。

9.VCSから VCSAへデーターコピーが行われます。(vSphere Web Client データのエクスポートなど)

10.VCSA の設定が行われます。

11.すべてのデーターが VCSAへインポートされてから、完了となります。

12.もし、以下のようなエラーが表示されたら、ブラウザのキャッシュをクリアしてみてください。

13.移行完了。

正常に vCenter 6.5 になっていることがわかります。

思ったより簡単に移行できそうではないでしょうか。

ぜひ、お試しください。

VCS (シャットダウン中)はそのまま残っている状態のため、もし移行が何らかの理由で途中失敗した場合でも簡単に切り戻しができるのもチャレンジしやすいところかと思います。

Tip：VCSでローカルアカウント設定を行っている場合は、移行前にユーザー権限を外してください。そうしないと、移行手順 9 のところ (vPostgres SQLあたり)で失敗する可能性があります。

[参考情報]

既知の制限事項

https://docs.vmware.com/jp/VMware-vSphere/6.5/com.vmware.vsphere.upgrade.doc/GUID-5E19B79A-AE4F-497A-9047-3E9AAC1D7767.html

vExpert 2018をいただきました。

CJです。

今朝の発表で、vExpert 2018をいただきました。

個人的には今まで取得してきた資格とは違う性質のもので、非常に光栄であり・嬉しく思っております。これからも得た知識・経験を極力わかりやすい形でシェアしていきたいと思います。

よろしくお願いします。