MENU

ESXi→Hyper‑V変換でMVMCがログインできない時の原因と対処（認証エラー/TLS/互換性/代替手段まで解説）

Hyper-V
ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

ESXi→Hyper‑V 変換時に MVMC で「資格情報は正しいのにログインできない」を解決する

VMware ESXi／vCenter 上の仮想マシンを Microsoft Virtual Machine Converter（MVMC） で Hyper‑V 形式に変換しようとしたところ、認証エラーで先へ進めない——この相談は今でも非常に多いテーマです。本記事では、現場で遭遇しやすい原因と確実に効く対処を、手順・コマンド・チェック表まで含めて徹底解説します。MVMC は既に開発終了しており最新環境では不安定になりがちですが、それでも通すための実践テクニックと、代替ルートをまとめて紹介します。

この記事の想定読者

  • vSphere（ESXi／vCenter）から Hyper‑V へ移行する必要がある管理者
  • MVMC で vCenter または ESXi に接続 できたりできなかったり する不安定さに困っている方
  • 最新の vSphere 6.7／7.0／8.x で TLS まわりの相性 に悩んでいる方

よくある原因を 1 枚にまとめる（早見表）

症状考えられる原因すぐ試せる対処
「資格情報が無効」や「認証に失敗しました」ドメイン経由の権限不足、vCenter SSO ドメインの指定ミス、ロックアウトESXi 直の root または vCenter の [email protected] で接続
「SSL/TLS セキュア チャネルの信頼関係が確立できません」自己署名証明書／期限切れ証明書、名前解決不一致（FQDN≠証明書CN）接続先を証明書の CN/SAN と一致する FQDN へ変更、信頼済みルート に証明書をインポート
「基になる接続が閉じられました」やハンドシェイク失敗TLS 1.0/1.1 が無効、MVMC が TLS 1.2 を掴めていないWindows の .NET Strong Crypto を有効化（後述のレジストリ）
vCenter だと失敗、ESXi 直だと成功／逆もvCenter 経由の API 差異・プラグイン干渉・証明書チェーン問題vCenter を迂回して ESXi ホストへ直接 接続、またはその逆を試す
突然つながらなくなったポリシーで TLS/暗号スイートやプロキシ設定が変更ポート 443/902 の疎通・プロキシ・TLS 設定 をチェック
そもそも認証が安定しない製品の互換性（MVMC は古い）Azure Migrate／SCVMM／オフライン変換 に切替

まずはこれだけ：成功率を一気に上げる 5 つの即効対処

  1. アカウントを変える：ドメインユーザーではなく、ESXi 直の root、または vCenter 純正の [email protected] を使用。
  2. 接続先を変える：vCenter で失敗するなら 対象 VM が載る ESXi ホストへ直接 接続（IP 直指定）。
  3. .NET Strong Crypto を有効化：MVMC 実行サーバーで TLS 1.2 を使うようレジストリ設定（後述）。
  4. 証明書を信頼させる：vCenter/ESXi のサーバー証明書を ローカル コンピューターの信頼されたルート にインポート。
  5. 疎通確認：443/902 の TCP を Test-NetConnection でチェック、プロキシや DNS の影響を除外。
# 疎通チェック（Windows PowerShell）
Test-NetConnection -ComputerName <vcenter_or_esxi> -Port 443
Test-NetConnection -ComputerName <esxi_host_ip> -Port 902
# 時刻同期（±5分以内が目安）
w32tm /query /status
# WinHTTP プロキシ（必要なら明示設定/解除）
netsh winhttp show proxy

MVMC の仕様と互換性の注意点

MVMC は 2017 年に開発終了 したツールです。公式に見合った互換性は vSphere 5.x／6.0 世代 が中心で、6.7／7.0／8.x では認証 API や TLS/暗号スイートの差分により失敗しやすくなります。最新の Windows Server／Windows 11 側でも TLS 1.0/1.1 が無効化されていることが多く、MVMC が TLS 1.2 を掴めないケースで「資格情報が正しいのに認証失敗」という表面的な症状になります。

TLS/SSL 周りの安定化：.NET Strong Crypto を有効化

MVMC は .NET を利用します。OS 側で TLS 1.0/1.1 を無効化済みの環境では、MVMC が TLS 1.2 を必ず選択するよう、以下の レジストリ設定（Strong Crypto） を導入すると成功率が上がります。

レジストリ（TLS 1.2 を強制利用しやすくする）

Windows Registry Editor Version 5.00

; 64bit OS での .NET 既定暗号を強化（TLS 1.2 優先）
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

ポイント：企業ポリシーで TLS 1.0/1.1 を無効化しているなら、無理に TLS 1.0 を再有効化しないのが原則です。まずは Strong Crypto を有効化して TLS 1.2 での接続確立を狙います。

（やむを得ない場合のみ）TLS 1.0/1.1 を一時的に開ける

検証用セグメントでの暫定回避として、クライアント側に TLS 1.0/1.1 を一時的に有効化する方法もあります。ただし セキュリティ低下のため、本番での恒久運用は推奨しません。必ず作業後に元へ戻してください。

Windows Registry Editor Version 5.00

; クライアント側 TLS 1.0/1.1 を一時的に有効化（例）
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"Enabled"=dword:00000001
"DisabledByDefault"=dword:00000000

再起動後に MVMC 接続を試し、完了後は Enabled=0 / DisabledByDefault=1 へ戻しておきます。

アカウントと権限：誰で接続すべきか

接続先推奨アカウント理由注意点
ESXi 直root認証経路が最短。SSO や外部 ID 連携の影響を受けにくいroot が無効化されていないか確認。ロックアウトポリシーに注意
vCenter[email protected]vCenter 組み込み SSO でフル権限。ドメイン権限の継承ミスを回避SSO ドメインを @vsphere.local まで含めて明示入力
ドメインユーザー最小権限のロール＋必要特権監査要求が厳しい環境での代替VM.PowerOff/On、VM.Migrate、Datastore.Browse などの特権を網羅

ユーザー名の入力ミス（administrator だけ入れて @vsphere.local を忘れるなど）や、ローカル／ドメインのコンテキスト違いが、「パスワードは正しいのに失敗」の定番要因です。

vCenter を使うか、ESXi 直で行くか

  • vCenter 経由で不安定：証明書チェーンやプラグイン、API の差異が絡みやすい。
    → ESXi ホストの IP を直接指定して接続。
  • ESXi 直で失敗：ホスト個別の設定差（TLS/証明書/ポート）で弾かれている可能性。
    → vCenter 経由（クライアント証明書が適切なケース）を試す。

証明書・名前解決・時刻：TLS を安定させる三種の神器

  1. 証明書の信頼：vCenter/ESXi のサーバー証明書（自己署名含む）を ローカル コンピューター の「信頼されたルート証明機関」へインポート。
    証明書の CN/SAN と接続先（FQDN）の一致が重要。IP 直指定時は CN と合わずに失敗することも。
  2. 名前解決の一貫性：MVMC 実行サーバーの DNS で nslookup を実施し、逆引きも含め整合を確認。
  3. 時刻同期：クライアントと vCenter/ESXi の時刻差が大きいと TLS 失敗・トークン無効の原因になります。w32tm で確認し、±5 分以内を維持。

ネットワーク要件（ポート／プロキシ／FW）

方向ポート用途備考
MVMC → vCenter/ESXi443/TCPAPI／管理プレーン（HTTPS）プロキシ経由だと握手に失敗することあり。例外設定推奨
MVMC → ESXi902/TCPデータ転送（NFC）FW/IPS が切っていないか確認
# 代表的な疎通チェック
Test-NetConnection vcenter.example.local -Port 443
Test-NetConnection 10.0.0.21 -Port 902

# プロキシ回避（必要な場合のみ実施）
netsh winhttp set proxy proxy-server="http=myproxy:8080;https=myproxy:8080" bypass-list="<vcenter_fqdn>;<esxi_ip>"
# あるいは一時的に直接接続
netsh winhttp reset proxy

MVMC がやっぱり不安定なら：代替ルートを選ぶ

オンライン移行の代替

  • Azure Migrate：評価＋移行をまとめて行える Microsoft 製の現行手段。vSphere 7/8 世代でも安定。
  • System Center Virtual Machine Manager（SCVMM）：Hyper‑V 向けの V2V（VMware→Hyper‑V）機能を備え、ジョブ管理・再試行も強い。

オフライン変換の代替

  • vCenter Converter Standalone：VM を VMDK としてエクスポート。
  • qemu-img / StarWind V2V Converter など：VMDK → VHDX（可変／固定）へローカル変換。
  • Hyper‑V Manager：新規 VM を作成して VHDX を接続し起動。必要に応じてブート修復。

オンライン変換が難しいネットワーク／セキュリティ制約下では、オフライン変換のほうが総工数が安定することが多いです。

実践：オフライン変換の手順（確実に通す版）

  1. VM の準備
    • Windows なら VMware Tools をアンインストール（再起動）。
    • Linux なら open-vm-tools をアンインストール（必要に応じ）し、Hyper‑V 用モジュール（hv_*） が利用可能なカーネルであることを確認。
    • スナップショットを統合して I/O を安定化。
    • BitLocker 有効時は manage-bde -protectors -disable C: で保護を一時停止。
  2. シャットダウン → VMDK を取得
    データストア ブラウザーで VM の VMDK をダウンロード、または ESXi で vmkfstools -i を利用して一旦フラット化（シン→シック化）すると変換が安定します。
  3. VMDK → VHDX へ変換
    # 例：qemu-img で可変 VHDX に変換 qemu-img convert -p -f vmdk source.vmdk -O vhdx -o subformat=dynamic target.vhdx
    • サイズ最適化を重視する場合：-o subformat=dynamic
    • 性能重視：固定 VHDX を選択
  4. Hyper‑V 側で VM を新規作成
    • ファームウェア種別の対応：ESXi で BIOS → Hyper‑V Generation 1、ESXi で EFI → Generation 2
    • Gen1 の起動ディスクは最初 IDE 接続が安全（後で SCSI に移行可）
  5. 初回起動とブート修復
    • Windows：起動に失敗したら WinRE で bootrec /fixmbr、bcdboot C:\Windows /f ALL を実行
    • Linux：ディストリごとに update-initramfs -u or dracut -f、必要なら grub2-install
  6. ドライバーと統合サービス
    • Windows 10/Server 2016 以降は Hyper‑V 統合サービスが OS 標準。古い OS は Windows Update で最新化。
    • 古い仮想 NIC（VMXNET など）が残って IP 重複を起こす場合は、
      set devmgr_show_nonpresent_devices=1 → デバイス マネージャーで 非表示デバイスを削除

「ログインできない」時に現れやすいメッセージと対処

メッセージ（英語系）概要対処
The underlying connection was closed.TLS ハンドシェイク失敗／暗号スイート不一致.NET Strong Crypto、証明書信頼、FQDN 一致
Could not establish trust relationship for the SSL/TLS secure channel.証明書が信頼されていない／CN 不一致証明書を 信頼済みルートへインポート、接続先を CN/SAN に合わせる
Authentication failed because the remote party has closed the transport stream.サーバー側が握手を切断ポリシー変更（TLS/暗号）確認、ESXi 直で再試行
Invalid credentials / Cannot complete login due to an incorrect user name or password.ユーザー名のコンテキスト違い、権限不足root（ESXi） or [email protected]（vCenter） で再試行

ログの場所と切り分けのコツ

  • MVMC のログは %LOCALAPPDATA% や %ProgramData% 配下に生成されます（フォルダー名例：Microsoft Virtual Machine Converter）。環境によりパスが異なるため、フォルダー検索で Converter / VMConverter を探してください。
  • Windows の イベント ビューアー > アプリケーション に .NET 例外や Schannel（TLS）エラーが記録されます。

PowerCLI で「資格情報が本当に通るか」を先に確かめる

MVMC 自体の UI で詰まるより先に、PowerCLI で認証だけ確かめると切り分けが早いです。

# PowerCLI の例（事前に PowerCLI をインストール）
# vCenter へ
Connect-VIServer -Server vcenter.example.local -User "[email protected]" -Password "*****"

# ESXi へ直接

Connect-VIServer -Server 10.0.0.21 -User "root" -Password "*****"

ここで成功するのに MVMC だけ失敗する場合、MVMC 固有の TLS/証明書取り扱いが原因の可能性が高いです。

移行後に起きがちな OS 側の課題と解決

Windows ゲスト

  • NIC が入れ替わるため固定 IP が消える：
    netsh interface ip show config で確認し、必要に応じて再設定。
  • 古い VMware 仮想デバイスが残る：
    set devmgr_show_nonpresent_devices=1 → 非表示デバイスを削除。
  • ブート修復：
    bcdboot C:\Windows /f UEFI（Gen2）/ /f BIOS（Gen1）で再生成。

Linux ゲスト

  • 新しい仮想 NIC 名（例：eth0 -> ens33 相当）が割り当て直されるため、/etc/netplan や /etc/sysconfig/network-scripts を修正。
  • ディスク識別子：/etc/fstab が /dev/sdX 直書きなら UUID に置換。
  • initramfs 再生成：update-initramfs -u もしくは dracut -f。

セキュリティ観点のベストプラクティス

  • 一時的に緩めた TLS 1.0/1.1 は作業完了後に必ず 無効化へ戻す。
  • 移行アカウントは 専用の一時アカウント を用意し、作業後に無効化。
  • 移行トラフィック（902/443）は 専用 VLAN で隔離し、完了後は閉塞。

チェックリスト（印刷して使える簡易版）

項目確認
接続先は vCenter と ESXi 直の両方で試したか□
アカウントは root or [email protected] を使用したか□
証明書は信頼ストアに入っているか（CN/SAN と FQDN が一致）□
.NET Strong Crypto（TLS 1.2 優先）は有効か□
443/902 の疎通とプロキシ例外は設定済みか□
時刻同期（±5 分以内）はできているか□
オンラインで難しい場合は代替（Azure Migrate/SCVMM/オフライン変換）に切り替えたか□

まとめ：最短で成功させる判断基準

  • まずは ESXi 直の root か vCenter 組み込み [email protected] で接続。
  • .NET Strong Crypto を有効化して TLS 1.2 を優先、証明書信頼＋FQDN 一致を徹底。
  • それでも不安定なら、vCenter／ESXi 直を切り替えて試行。
  • オンラインに固執せず、Azure Migrate／SCVMM／オフライン変換にスイッチして確実に完了させる。
  • 作業後は TLS 設定の巻き戻し と 権限の回収を忘れない。

MVMC は古いツールであるがゆえに、ネットワーク・証明書・TLS・権限という基礎を一つずつ正していけば、まだ十分に「通す」ことができます。最短での成功は、正しい接続先と正しいアカウント、そして TLS の整備から始まります。

付録：レジストリ適用スクリプト（PowerShell）

# 管理者で実行：.NET Strong Crypto を有効化（32/64bit の両方）
$paths = @(
  "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319",
  "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319"
)
foreach ($p in $paths) {
  New-Item -Path $p -Force | Out-Null
  New-ItemProperty -Path $p -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWord -Force | Out-Null
}
Write-Host "Enabled .NET Strong Crypto (TLS 1.2 preference). Please reboot if required."

付録：Hyper‑V 世代選択の目安

ESXi 側の VM 設定Hyper‑V の世代（推奨）備考
ファームウェア：BIOSGeneration 1起動ディスクは IDE から開始、後で SCSI 可
ファームウェア：EFIGeneration 2UEFI ブート、セキュア ブートは OS に合わせて設定

FAQ

Q. vCenter では必ず失敗します。ESXi 直なら成功します。なぜ？
A. vCenter を挟むと証明書チェーン・API バージョン・プラグインの影響を受けます。ESXi 直での接続は経路が単純で安定しやすいです。証明書を信頼させ、FQDN と CN/SAN を合わせてから再度 vCenter で試すと改善することがあります。

Q. ドメインの管理者アカウントでも通りません。
A. vCenter の SSO とディレクトリ連携の設定が原因で、権限が足りない／別ドメインとして扱われているかもしれません。[email protected] での試行を優先してください。

Q. TLS を緩めてもダメでした。
A. MVMC 自体の互換性限界の可能性があります。Azure Migrate／SCVMM／オフライン変換へ切り替えるほうが結果的に早く、安全で確実です。

実務での推奨フロー（決断ツリー）

  1. 要件確認：停止可／不可、許容ダウンタイム、ネットワーク制約、セキュリティ制約。
  2. MVMC 試行（2 時間以内の目安）：ESXi 直 or vCenter、root/[email protected]、.NET Strong Crypto、証明書信頼、443/902 開通。
  3. 通らなければ即スイッチ：ダウンタイムを抑えたい→Azure Migrate／SCVMM。
    長期停止でも可→オフライン変換＋Hyper‑V 新規 VM。
  4. 移行後チューニング：統合サービス更新、NIC/IP 再設定、ディスク最適化、バックアップ整備。

補足：MVMC は既に EoL（開発終了）であり、最新 OS／vSphere との組み合わせは「動いたらラッキー」な側面があります。長期運用を見据えるなら Azure Migrate または SCVMM への移行を中期計画に含めることをおすすめします。

この記事がカバーした要点：

  • ESXi→Hyper‑V 変換時に MVMC がログインできない典型原因と対策
  • .NET Strong Crypto／証明書／ポート／時刻の整備で成功率を上げる方法
  • MVMC が不安定な場合の現実的な代替手段（オンライン／オフライン）
  • 移行後に起きやすい OS 側の修正ポイント
Hyper-V
Hyper-V TLS MVMC ESXi 仮想化移行

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次