Nutanix CE よろず相談所


Userlevel 3
Badge +5

Nutanix Community Edition(CE)に関する話題はこちらへどうぞ。


35 replies

@smzksts さま

お世話になっております。

ご回答ありがとうございました。

UEFIブートは本番機で試してみることにします。

Userlevel 3
Badge +5

@Takayuki Momose さま
CE 202.09.16ですと仮想マシンのUEFIブートにいくつか問題があるようでして、
acli vm.nic_create <VM_NAME> model=e1000 network=<VM_NETWORK_NAME>
という感じでNICをVirtIOではなくe1000に妥協することで一応NIC付きでの起動まで行けるのですが、Windows Server 2019や2016では、その後OSのインストーラーで、ドライバーを読み込ませた後のステップにBSODになってしまいました。

私の方では有効な手立てを持ち合わせておらず、本バージョンではLegacy Bootでお使いいただくことをオススメしております…。

お世話になります。
NutanixCE(2020.09.16)で仮想マシンのUEFIブートは可能でしょうか。​​
NutanixCE(2020.09.16)で仮想マシン(Win2019)をUEFIブートで起動させるとUEFI画面で固まってしまいます。
NICを外した状態だと通常起動されるのですが、NICを付けると起動できなくなります。
環境としては、Nutnaix-VirtIO-1.1.5iso、セキュアブートなし、ディスクはideでやっております。

 

 

お世話になります。

SSHクライアントの縦横の表示文字数(ウィンドウサイズ)を目一杯広げてからインストーラーを再実行してみてはいかがでしょうか?

 

ご推察・ご指摘の通りでした…。

SSH経由操作だけでスクリーンサイズ不足のエラーを回避できるものと思い込んでおり、

恥ずかしながら、エラーメッセージの文意通りの事を試しておりませんでした。

 

その後無事仮想マシン構築までたどり着けました。

実は今回、このためだけに環境を一式揃えたもので、

お陰様で10万円超の出費が無駄にならずに済みそうです。

本当にありがとうございました。

 

Userlevel 3
Badge +5

> 成功時の確認ですが、一般的なUSBメモリにて2020.09.16版のiso利用という事で良いでしょうか?

こちらについては、一般的なUSBメモリで通常の2020.09.16版のISOを利用しています。NICドライバだけはオンボードのRealtekをインストーラーが自動認識できないので、自分でビルドしたものを使いました。

Userlevel 3
Badge +5

 

Terminal screen is not large enough to run the installation script. Please resize the terminal and rerun the script.

というメッセージが最後に出ているので、SSHクライアントの縦横の表示文字数(ウィンドウサイズ)を目一杯広げてからインストーラーを再実行してみてはいかがでしょうか?

成功した環境ですとSSHクライアントはWindowsでTeraTermを使用し、縦横の表示文字数を増やして(ウィンドウサイズを大きくして)からインストーラーを再実行することで成功しています。

逆に、SSHクライアント経由でもウィンドウサイズを変えていなかったり、広げ方が不十分だったりすると、ローカルコンソールと同様に↑のメッセージが出て失敗します。TeraTermもデフォルトの80x24文字だと小さ過ぎてエラーになりました。BIOS設定は特に変更していなかったと記憶しています。

ご回答いただきありがとうございます。

改めてTeraerm利用しSSH経由で実施してみましたが、状況変わらずで、画面表示は以下の通りでした。

2021-11-23-06:45:58-UTC ./ce_installer: line 298: [: too many arguments
2021-11-23-06:45:58-UTC Loading drivers
2021-11-23-06:45:59-UTC Removing the built-in i40e driver and reloading the new i40e driver
2021-11-23-06:45:59-UTC Getting DHCP address for phoenix
2021-11-23-06:45:59-UTC dhclient(3699) is already running - exiting. 
2021-11-23-06:45:59-UTC 
2021-11-23-06:45:59-UTC This version of ISC DHCP is based on the release available
2021-11-23-06:45:59-UTC on ftp.isc.org.  Features have been added and other changes
2021-11-23-06:45:59-UTC have been made to the base software release in order to make
2021-11-23-06:45:59-UTC it work better with this distribution.
2021-11-23-06:45:59-UTC 
2021-11-23-06:45:59-UTC Please report for this software via the CentOS Bugs Database:
2021-11-23-06:45:59-UTC     http://bugs.centos.org/
2021-11-23-06:45:59-UTC 
2021-11-23-06:45:59-UTC exiting.
2021-11-23-06:46:01-UTC Running /ce_installer
2021-11-23-06:46:01-UTC INFO Installing /usr/lib/python2.7/site-packages/foundation_layout-99.0+r.1284.8348b43-py2.7.egg
2021-11-23-06:46:01-UTC INFO /root/components doesnt exist
INFO Model detected: CommunityEdition
INFO vpd_info {'vpd_method': None}
INFO Generating cluster_id
INFO node_serial = f4c4400e-d133-4eda-a9d0-139c3a6c1082, node_uuid = 53bca156-ef55-4e00-b196-e050faa32fd3, block_id = , cluster_id = 2739627187682289439, model = USE_LAYOUT, model_string = CommunityEdition, node_position = 
INFO Getting NOS version from the CVM
INFO Phoenix ISO is already mounted
INFO Getting AOS version from /mnt/iso/images/svm/nutanix_installer_package.tar.p00, This may take a few minutes if phoenix is running from BMC
Terminal screen is not large enough to run the installation script. Please resize the terminal and rerun the script.


[screen is terminating]
[root@phoenix ~]# 

個人的にはINFO /root/components doesnt existの表示が気になっているところです。

成功時の確認ですが、一般的なUSBメモリにて2020.09.16版のiso利用という事で良いでしょうか?

BIOS(UEFI)の設定も特に変更不要でしょうか?

質問ばかりで申し訳ありませんが、よろしくお願いいたします。

Userlevel 3
Badge +5

junk01さん、すみません返信遅くなりました。

M75sでインストール成功しているのは私の自宅環境ですね。

このマシンだとブートデバイス優先度の変更では成功しなかったため、SSH経由でインストールしました。

また、ディスク構成は下記のとおりです。記載いただいている環境と大きな違いはないように思います…。

AHV→NVMe SSD(120GB)

CVM→SATA-SSD(2TB)

Data→SATA-SSD(2TB)


Screen is terminatingとなってしまう場合、Teraterm等のログ機能を使って、Terminatingの表示になる直前にどのようなエラーが表示されていたのかを確認すると解決のヒントになるかもしれません。

UEFI起動順を設定してもエラーになり、SSH経由でリトライしても[screen is terminating]となり

インストールに進めない事象となります。

上記続報、自己レスです。

ストレージの接続や構成をいろいろと変更して試していたところ、起動用USBを含め、物理ストレージが4台以上となると上記の事象となる様です。

4台すべてUSB経由⇒NG

USBBoot+3台SATA接続⇒NG

SATABoot+2台SATA+1台nvme⇒NG

SATABoot+2台SATA⇒TUI起動するが、NextPageを選択で同様のスクリーンサイズ不足エラー発生。

(そもそもBoot imageを保持するディスクに対しH/C/Dを選択せざるを得ない構成)

SATAorUSB Boot+1台SATA+1台nvme⇒同上

今回利用しているLenovo M75s Gen2はSpeaker Deckのスライドp18にも言及があり、

インストールの実績があるものと思いますが成功された方はどのようなストレージ構成だったのでしょうか?

BIOS(UEFI)の設定変更やインストールスクリプトの変更などが必要なのでしょうか。

ご存じの方がいらっしゃいましたらぜひ情報提供をお願いします。

 

 

 

お世話になります。junk11と申します。

徹底解説のスライドを参照しCEの5.18インストールを試みているのですが20pの記載に従い

UEFI起動順を設定してもエラーになり、SSH経由でリトライしても[screen is terminating]となり

インストールに進めない事象となります。

https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=20

 

H/W構成の概要は以下の通りです。

Lenovo ThinkCentre M75s Small Gen2

Ryzen7 PRO 4750G 32GB

samsung 970 EVO Plus 2TB(Hot Tier:nvme0n1)

Seagate ST8000DM004 8TB(Cold Tier:sdb)

intel SSDSA2M080G2GC 120GB(HV起動用:sda)

KIOXIA USB3.2 Gen1 32GB(iso起動用:sdc)

[root@phoenix ~]# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0    0   1.8T  0 disk
sdb       8:16   0   7.3T  0 disk
sr0      11:0    1  1024M  0 rom
loop0     7:0    0   194M  0 loop
sdc       8:32   1  28.9G  0 disk
└─sdc1    8:33   1  28.9G  0 part /mnt/iso
sda       8:0    0 111.8G  0 disk
└─sda1    8:1    0 111.8G  0 part

 

事前の情報収集にてできるだけ実績のある(ありそうな)ものを

チョイスしたつもりですが、行き詰り、困り果てております。

何のどこから確認したものか、ヒントだけでもいただければ幸いです。

以上、よろしくお願いいたします。

こんにちは。

https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=56

上記の56スライド目以降を拝見して、Nutanix CE 5.18にESXiをインストールするときに必要なLocal VMFS有効化を行おうとしましたが、インストール後リブート前に/dev/sdd5 をマウント時にdoes not exitと返されてしまい、/dev/sda5 の起動用のjsonファイルの該当箇所は元から

"user_vmfs?_datastore":"true"

となっているのですが、そのままrebootをかけるとFaild-Installになってしまいますが、
ssd5のパスは環境によってかわりますでしょうか。(ls /dev で確認したところssd1のみ確認できましたが/Nutanix以下のディレクトリはなし)

■試したESXiバージョン
7.0U2a-17867351
7.0-15843807
6.7-14320388

何卒宜しくお願い致します。

自己解決済み

7.0U2a-17867351
7.0-15843807

→VMFS参照不可


6.7-14320388

→VMFS参照可,CVMの起動に失敗していたので,スライド62以降の手順でpyスクリプトの修正・再実行・Clusterの手動作成にて無事Prsim起動いたしました。

こんにちは。

https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=56

上記の56スライド目以降を拝見して、Nutanix CE 5.18にESXiをインストールするときに必要なLocal VMFS有効化を行おうとしましたが、インストール後リブート前に/dev/sdd5 をマウント時にdoes not exitと返されてしまい、/dev/sda5 の起動用のjsonファイルの該当箇所は元から

"user_vmfs?_datastore":"true"

となっているのですが、そのままrebootをかけるとFaild-Installになってしまいますが、
ssd5のパスは環境によってかわりますでしょうか。(ls /dev で確認したところssd1のみ確認できましたが/Nutanix以下のディレクトリはなし)

■試したESXiバージョン
7.0U2a-17867351
7.0-15843807
6.7-14320388

何卒宜しくお願い致します。

Nutanix Filesについてご教示ください。

CE(202009)にてサポートされたと聞き試行したところ、毎回タスクが下記メッセージにてエラー停止します。

「Cannot complete request in state InvalidVmState: Cannot complete request in state Paused」

確かにVMタブを見ていると、いったんFile Server VMがパワーオンし、その後ポーズ状態に遷移し削除されています。何か思い当たる解決策がありましたら、ご教示ください。

 

smzksts 様

 

上記の状態ですが、例えば途中で中断したアップグレードを再開させるコマンドなどは無いでしょうか?

途中で再起動するようなことをしてしまっているのでうまく完了するとは限らないのですが、試してみる価値は無いでしょうか。

その後、クラスタのステータスなどを調べて、4台中3台のCVMでscavengerサービスが起動していないことがわかりました。

起動しているのはアップデートが正常完了?したホストの1台だけです。

また、ncliやacliを実行するとconnection refusedとなり、zookeeper.outにも同様に

ZOO_ERROR@handle_socket_error_msg@2185: Socket [xx.xx.xx.xx:9876] zk retcode=-4, errno=111(Connection refused): server refused to accept the client

が延々と記録されている状況です。

 

ここがクリアになれば先に進める気がするのですが、何か情報は無いでしょうか?

 

いつもお世話になっております。

 

以下リンク先の内容に沿って、アップグレードを実行してみました。

https://blog.ntnx.jp/entry/2020/09/30/235747

 

4台ホストのクラスタ中、1台だけは普通にアップグレードが完了(タスク一覧で100%になりました)したように見えましたが、残り3台が73%のまま数日待っても変化無しという状態です。

あまりに状況に変化が無いままでしたので、一旦クラスタを停止して、ホストの再起動を行ったところ、クラスタが起動しなくなってしまいました。

 

cluster start

→WARNING genesis_utils.py:1199 Failed to reach a node where Genesis is up. Retrying... (Hit Ctrl-C to abort) ※24行くらい繰り返し

Waiting on xx.xx.xx.xx (Up, ZeusLeader) to start:  IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx(Up) to start:  IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx (Up) to start:  IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx (Down) to start:

~中略~

The state of the cluster: Unknown
 Lockdown mode: Disabled

 CVM: xx.xx.xx.xx Down →4台分

と表示されています。

 

genesisが起動していないのかなと思い、

genesis start

すると、already runningとなるので起動はしているように見えます。

CVMから「ping 192.168.5.1」は4台すべて通っています。

 

何かクラスタを復旧する方法は無いでしょうか?

 

smzksts 様

 

お世話になっております。

また大分時間が開いてしまいましたが、破損ホストの削除不可、一部仮想マシンの操作不能(グレー表示)の件で結果報告いたします。

 

 

Acropolisのマスター再起動は、既に試していたようです。

残してあった操作のメモ見たら、同じKBを参照して対応していました。

残念ながらAcropolis再起動では解決しなかったようです。

 

仮のクラスタは問題なくリモートDRで仮想マシンの移動ができて動作確認もできましたので、すべてのホストを新規クラスタで作り直しました。

現在は、仮クラスタの仮想マシンを戻し、すべて正常に動作するようになりました。

ありがとうございました!

※いろんなテストをしていたので、かえってこれでスッキリきれいな環境になってうれしい面もあります。

 

今回の一件で、NutanixCEでいろいろテストしていく上で結構リモートDRは良いなぁと感じました。

最悪クラスタを破壊するようなことがあっても、あっさり戻せるのは安心感があります。

※10GLANということもあるかもしれませんが、あまりに速くて逆に心配になったくらいです。

NGTを入れていない仮想マシンも多かったので、今回は仮想マシンをシャットダウンしてからスナップショットを取るようにして移行しましたが、NGTを入れておけば活動中でも大丈夫そうです。

このあたりはもう少しテストしてみようと思います。

 

さて、再構築したときに気付いたのですが、いつの間にか新しいバージョンがリリースされていたのですね。

こまめにPrismでアップデートの確認していてもNCCとFoundation以外は出てきていなかったので、そのまま2019.11.22版で再構築したのですが、コミュニティ見ると2020.09.16版になっていて驚きました。

Prismのアップデートでは検出されませんでしたが、「バイナリのアップロード」でアップデートしても問題は無いでしょうか?

なんとなく順序としては、

  1. AOSのアップデート
  2. AHVのアップデート
  3. PrismCentralのアップデート

こんな感じなのかなと思っていますが、合ってますでしょうか。

 

smzksts 様

 

だいぶ間が開いてしまい恐縮ですが、一部仮想マシンが削除できない&ホストも削除できないの件で、少し前進しました。

 

Acropolisのマスター再起動はまだ試していませんが、別のクラスタをシングルノードで構築してリモートDRでクラスタ跨いでスナップショットを取る、というのをやってみました。

 

結果としては、灰色になって起動も削除もできなかった仮想マシンを含め(少々驚きました)、スナップショットの取得に成功、別のクラスタ上で正常に起動することも確認できました。

灰色になった仮想マシンの復旧方法としても使えそうです。

 

とりあえず必要そうな仮想マシンを新しいクラスタに一旦退避して、何が起きても大丈夫な状態でAcropolisのマスター再起動も試してみようと思います。

 

業務の合間で試しているのでなかなか進みませんが、また報告させていただきます。

Userlevel 3
Badge +5

Twitter等では紹介していたのですが、CE関連の資料を作ったのでコチラにも載せておきます!

Nutanix CE 5.18のインストールに関する詳細解説資料です。
インストール周りで躓きがちなポイントとその回避方法をたくさん載せてますので、
上手くいかないときにまずはご一読くださいませ。

Nutanix Community Edition 5.18 徹底解説 (Speaker Deck)

smzksts 様

 

他のホストは正常に動作していますので、グレー以外の仮想マシンの変更や新規作成には問題ありません。

 

ホスト(クラスタ)の再構築は最終手段としてある程度覚悟はしていました。

スペックはかなり落ちるものの、一時的な受け皿とするための機材は何とかなりそうですので、最悪そうしないといけないね、と内輪では話をしていた感じです。

仰るとおり、かなりいろいろなテストをしたりホストの差し替えを頻繁に行ったりで無茶している環境ではありますので、このあたりですっきりと整理しても良いかなと思っています。

 

まだご提示いただいたKBの内容は読み切れていませんが、なんとなく一致しそうな気がしています。

Acropolisサービスのマスター再起動はまた後日試してみて、解決しなければ一時的に別のクラスタ作ってAsyncDRで逃がしてクラスタを1から再構成することを計画しようと思います。

 

CE版にも関わらず、いろいろアドバイスいただけてむしろ感謝しております。

また少し間が空くと思いますが、結果などは報告させていただきますのでよろしくお願いします。

 

Userlevel 3
Badge +5

@Muneto さん

PCの削除もノードの削除もレスポンスが無いというのは気になりますね…。
他のVMの作成/削除には支障ない状態でしょうか?

ご認識のとおり、acli vm.delete にはforceオプションはありません。本来、デフォルトでforceな形で処理されるものです。

MARKED_FOR_REMOVAL_BUT_NOT_DETACHABLEをキーワードとして検索して、他に関連しそうな公開KBとしては下記のもの程度でした。

AHV | Node removal stuck after successfully entering maintenance mode
https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e0000009D6CCAU

もしもこちらの状況に合致するようであれば、回避策として、Acropolisサービスのマスターを再起動する、という方法も考えられます。

  1. 任意のCVMのCLIにログインし
    links http://127.0.0.1:2030
    というコマンドを実行すると、テキストベースのウェブブラウザが実行されます。
  2. Acropolisサービスの詳細が表示されますので「Acropolis Master」という項目を確認します。「this node」または他のCVMのIPアドレスが表示されます。
  3. Acropolis Masterの項目に表示されたCVMにアクセスし。下記のコマンドでacropolisサービスを再起動します。
    genesis stop acropolis; cluster start
  4. もしも手順3でも変化がない場合には、メンテナンスモードの無効化と有効化を手動で行います。
    acli host.exit_maintenance_mode <host IP or uuid>
    acli host.enter_maintenance_mode <host IP or uuid>

他にもKBを探してみたのですが、あいにくInternal向け(非公開)なものに限られておりました…不安定な状態で様々な対応を試行するのもリスキーな気もしています(商用版ならサポート部門が解析した上でより的確な対応策をご案内するのですが、なにぶんCEのため…)。

もしも大事なGuest VMがある&CEをインストール可能な機材が他にもありましたらAsync DRでデータの退避した上で再インストールを行うなどの対応も視野に入れておいて頂くのがよろしいかもしれません。

smzksts 様

 

大変お世話になっております。

 

Prism Centralを削除しなくても新規で接続するのは問題ないとのことで、また一つ前に進めそうです。

※すぐに使えないといけない予定も無いので、あとからじっくりやってみようと思います。

 

acli vm.delete は実行してみましたが、PCの仮想マシンは削除できませんでした。

試しに他の仮想マシンでもやってみましたが、以下のような結果でした。

・「仮想マシン」ー「テーブル」でグレーになっている仮想マシンはタスクが0%のまま進まない

・赤(停止中)で正常なホストにいる仮想マシンは何の問題もなく削除できる

・緑(起動中)の仮想マシンでは試していません

 

ホスト削除のncli host rm-start force=true も実行してみましたが、こちらも

Host removal successfully initiated

と応答はあるものの、前回同様にタスクが出てくる気配がない状態です。

 

何度かトライしているので裏で処理が進んでないタスクが残っているのではと思い、

https://next.nutanix.com/how-it-works-22/clear-out-stuck-tasks-31879?postid=39355#post39355

ここの情報を参考にして

ecli task.list include_completed=false

で表示されたタスクはすべて

~/bin/ergon_update_task --task_uuid=xxxxxxxxxxxxxxxxx --task_status=aborted

で中断してみましたが、ホストの削除もVMの削除も効果が無い状況です。

 

少しNutanixバイブル(日本語版)も見て確認してみたんですが、ncli vm.delete には force=trueのような強制するオプションは無いのですよね?

 

あと試してみたことは、削除できない仮想マシンのディスクを acli vm.disk_delete で削除してからならできないかな?とも思ったのですが、これ自体も0%のままで進みませんでした。

 

きっと障害が発生したときに、あとからホスト削除→再構築して再度追加ではなく、ブートディスク(USBメモリ)の復旧をすればこんなことにはならなかったと深く反省している次第です。

※何度もやっている手順でもあったので、作業者に指示しやすかった面もあったのですが・・・。

 

とりあえず、3台構成でもテストや評価は進められる部分も多いので、気長に対応していこうと思います。

Userlevel 3
Badge +5

@Muneto さん

ご報告ありがとうございます。

どうやらノードが削除できていないようですね…。
ncli host rm-startコマンドに force=true というオプションを追加すると成功するかもしれません。

また、古いPCは、PrismのGUI操作では削除できませんが、CVMのコマンドラインで 
acli vm.delete <Prism Central VM name> で消せるのではないかと思います。
(私自身も過去何度か、この操作で削除しています)

ただ、古いPCが残っていてもディスク容量の消費以外、干渉したりすることは無いはずですので、新しいPCをデプロイし、接続して頂いても問題ないと思います。

smzksts 様

 

大変お世話になっております。

ご提示いただいた情報をもとに、まず故障したホストの削除を試みてみました。

nutanix@cvm$ ncli host rm-start id=xxxxxx skip-space-check=trueHost removal successfully initiated

※xxxxxxは、「ncli host list」で確認した値

 

その後、「ncli host get-remove-status」で確認しますと、

    Host Id                   : xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    Host Status               : MARKED_FOR_REMOVAL_BUT_NOT_DETACHABLE
    Ring Changer Host Address : xx.xx.xx.xx
    Ring Changer Host Id      : xxxxxxxxxxxxxxxxxxxxx

この状態のまま変化がない状態が続いており、PEで見ると依然ホストが削除されないまま残っているように見えます。

念のため、タスクも「ncli progress-monitor list」で確認してみましたが、削除コマンド実行時の時間に近い(UTC表示でしたので、9時間足して確認しています)タスクは表示されませんでした。

 

追加:

最初の書き込みで書き忘れがありましたので、追記しておきます。

「ncli host list」の出力で、削除したいホストの「Metadata store status」は

    Metadata store status     : Node is removed from metadata store

となっております。

 

なおPrismCentralの接続解除は、ご提示いただいたKBの内容で正常に行えました。

仮想マシンは残っていますが、とりあえず一歩前進した感じです。PEで見ても「Prism Central に登録されていません」となっているので、大丈夫だと思います。

仮想マシンのテーブルに元のPCの仮想マシンが残っていることを気にしなければ、新規でPrismCentralをデプロイしても問題ないでしょうか。

 

ホストの削除は、時間がかかっているだけかもしれませんので、もう少し時間をおいて再度確認してみようと思います。

 

また進捗があればご報告させていただきます。

smzksts 様

 

参考情報誠にありがとうございます。大変助かります。

早速内容を確認して試してみたいと思います。

 

結果や状況に変化が出ましたら、あらためて報告させていただきます。

Reply