2020年3月20日金曜日

AHVのUEFIの対応と注意点

AOS5.16からUEFIのSecure Bootにも対応しました。
以前に、AOS5.11でUEFIには対応していましたが、UEFIへの対応強化となります。

では実際にUEFIで仮想マシンを作るところから見ていきたいと思います。

こちらはAOS5.16.1の環境の画面ですがAOS5.11以降、Prism画面からUEFIかBIOSかのどちらかを選択するモードが出てくるようになっています。

UEFIに関してはここから、UEFIを選択するだけです。

acliで確認すると、Prismで作成するとUEFIの領域が、ストレージコンテナが、ManagementShareに作成されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      uefi_boot: True
    }
    cpu_passthrough: False
    disable_branding: False


では、A Sync DRで他のNutanixクラスターにレプリケーションをする際にManagementShareのストレージコンテナも一緒にレプリケーション対象にする必要があるかというと、実際に動きを見たところ、ManagementShareのストレージコンテナをレプリケーション対象に入れなくても、問題なくレプリケーション及びリストア可能です。

現行UEFIでの起動に対応しているOSは、以下の通りです。
  • Windows Server 2012R2/2016/2019 (x64)
  • Windows 10 Pro/Home (x64)
  • CentOS 7.4/7.5/8.0 (x64)
  • RedHat Enterprise Linux 7.1/8.0 (x64)
  • Ubuntu 12.04.x LTS Desktop/Server (x64)
  • Ubuntu 16.04.x LTS Desktop/Server (x64)
  • Ubuntu 18.04.x LTS Desktop/Server (x64)
  • SUSE Linux Enterprise Server 12 SP3 (x64)

なお、Prism上でUEFIで仮想マシンを作成しても、セキュアブートモードにはなりません。
セキュアブートを有効にするには、acliで以下のコマンドを実行する必要があります。

vm.update 仮想マシン名 secure_boot=true machine_type=q35

secure_boot=trueと共に「machine_type=q35」の設定が必要となります。
セキュアブートが有効になると、以下のようにacliで確認するとsecure_boot:Trueと表示が追加されます。

vm.get UEFITEST1
UEFITEST1 {
  config {
    agent_vm: False
    allow_live_migrate: True
    boot {
      firmware_config {
        nvram_disk_spec {
          create {
            container_id: 8
            size: 540672
          }
        }
        nvram_disk_uuid: "b329af2f-1ad6-4698-a989-f11f87888c23"
      }
      secure_boot: True
      uefi_boot: True
    }
=中略=
    hwclock_timezone: "Asia/Tokyo"
    machine_type: "q35"
    memory_mb: 6144
    name: "UEFITEST1"

なお、セキュアブートに対応したOSは、AOS5.16時点で以下の通りです。

  • Windows Server 2016
  • Windows Server 1809
  • CentOS 7.3
  • Red Hat Enterprise Linix 7.7

  • なお、私が試した限りAOS5.16.1では、セキュアブートを有効にした状態で、Windows Server 2019はインストーラー画面の表示がされない(おそらく固まっている)事象を確認しています。
    このあたりはドキュメントに従って、アップデートを待つ必要があるようです。

    ▼UEFI起動時の仮想マシンのブート画面


    一方、セキュアブートでの起動時は、XマークではなくTianoCoreのロゴが表示されます。

    ▼セキュアブート時の仮想マシンブート画面


    また、セキュアブートを有効にした環境では、IDEバスを利用したCDROMドライブや仮想ディスクのマウントとはサポートされていません。セキュアブートの対応によりNGT(Nutanix Guest Tools)は、SATAデバイスのCDROMドライブでも対応することがAOS5.16.1で確認できております。

    UEFI利用時に1点だけ注意点があります。
    UEFI利用時にWindows OSを利用する場合、画面の解像度が800×600に固定され変更することが出来ません。これは、AHV上でVGAドライバーを提供していないことに理由があります。サーバーオペレーションの場合ほとんどがRDPやSSHなどリモートからの操作のため大きな影響はありませんが初期設定が800×600ですと、少々操作し辛い感があります。しかし、UEFIの設定画面で変更することが出来ます。

    ▼画面解像度が固定されている

    仮想マシン起動時にF2キーを押してUEFIの設定画面に入ります。
    [Device Manager]→[OVMF Platform Configuration]から[Change Preferred]で
    画面解像度を変更します。

    設定完了後、「F10」キーを押し、「Y」を押し設定を保存し、その後「ESC」→「ESC」でメインメニューに戻り、[Continue]を選択肢「Enter]キーを押します。
    そのままOSが起動しますが、まだUEFIの設定が反映されていませんので、一度OSを再起動すると新しいUEFIの設定が反映されます。


    なお、AOS5.10であってもUEFIでの設定は可能ですが、UEFIへの対応は正式にはAOS5.11から、セキュアブートはAOS5.16からのサポートとなります。
    AOS5.10でのUEFIで仮想マシンを稼動した場合、先程ご紹介した解像度の設定変更が正しく反映されない制限事項があります。

    AHVにおけるUEFIの対応は、AOS5.11以降急速に進んでいます。
    まだセキュアブートにおいてサポートされるOSが一部少ないなどの課題事項もありますが、これらは近いうちに修正されると思われます。

    Hyper-V 第2世代の仮想マシンからの移行などの場合は、UEFIでの利用が伴いますが、そういった場合も万全に対応可能です。

    2019年12月25日水曜日

    2019年の私とNutanixの振り返り

    2019年も残すところ後僅かとなりました。
    今までこのブログではNutanixの技術情報を中心に書いてきましたが、Advent Calendar 2019の最後である25日は、せっかくの機会ですので自分の振り返りと反省の意を込め、私自身が2019年どのようにNutanixに関わったか(振り回されたを含む)を書いてみたいと思います。



    2019年1月


    2019年2月


    2019年3月
    • Nutanix トレーニング受講
    • .NEXT Anaheimへの準備
    • Nutanix Certified Advanced Professional (NCAP) 5.5 取得


    2019年4月
    • 書籍執筆活動佳境を迎える
    • 社内Nutanixイベント対応で検証作業に追われる


    2019年5月


    2019年6月


    2019年7月
    • 社内Nutanixイベントの対応で環境作成等々に時間を要する


    2019年8月


    2019年9月


    2019年10月


    2019年11月


    2019年12月


    今年のNutanixとの関わりの代表的なものをピックアップしてみました。
    もちろんそれ以外にも、通常の業務でNutanixとの関わり合いは多くありますが、今年もいろいろな意味でNutanixと関わることが多かった1年だったと感じております。
    個人的には、アメリカでの骨折というのが、いろいろな意味での人生初な経験(二度と経験したくない)なところでしたが、そういったネタになる話しは毎度、Nutanix Meetupに登壇した際に話しております(資料の性質上、クローズドでないとお見せできない資料が多いので、いつも会場投影のみで対応させてもらっております)ので、まだNutanix Meetupに来られたことがない方は、是非参加してみて下さい。
    (私は今年7回登壇していたようです...)

    Nutanix Meetup 技術好きエンジニアのためのNutanix勉強会
    https://nutanix.connpass.com/



    来年もNutanixとのよいふれあいができる1年になればと思っております。




    HCIの苦手を克服するストレージ専用ノードの紹介

    HCIは、CPU、RAMを搭載するコンピュートとHDD、SSDなどの記憶領域であるストレージが一体となった製品です。
    一方で、HCIは、CPUやRAMよりもストレージ領域だけを多く利用した環境の場合、ストレージ容量を満たすまで、CPUやRAMも買い足さなければならないため、コスト的に割高になると言われることがあります。

    この言葉は、HCIの概念だけで言うと当てはまることかも知れませんが、Nutanixにおいては、この考え方は必ずしも当てはまりません。

    その答えとして、Nutanixは、ストレージ容量だけを増やすストレージノードが存在します。他社のHCIの場合、ストレージヘビーノードとして大きなストレージ容量を提供できるノードが販売されていますが、Nutanixの場合は、ストレージ専用ノードとして動作し、仮想マシンが稼働しないホストを提供します。

    しかし、ストレージ専用ノードと行っても、HCIである以上ハイパーバイザーも必要ですし、Nutanixの場合、CVMも必須コンポーネントになります。では、ストレージ専用のノードがどのようなメリットがあるのでしょうか。

    下の図を見て頂くと分かるのですが、Nutanixのクラスターは、ストレージ専用ノードと仮想マシンが稼働する部分のハイパーバイザーを混在して構成することが出来ます。

    ▼1つのクラスターでハイパーバイザーの混在が可能


    では、ハイパーバイザーが混在した環境の場合、ESXiで稼動している仮想マシンがAHVにvMotion出来るかというとこれはできません。この環境の場合、ストレージ専用ノードは、AHVがインストールされたノードになります。AHVが稼動するノードはCVMだけが仮想マシンが稼動し、Nutanixクラスター内でストレージ機能のみを提供します。このAHV上で仮想マシンが動作することはできません。

    Nutanixは異機種・異世代混在が可能ですから、ESXiで稼動する部分には、高速なCPUや多くのメモリーを搭載し、ストレージ専用ノードは最小限のCPUとメモリーを搭載することで、ストレージにおけるエンクロージャーの追加のように低コストでストレージ容量だけを増やすことが出来ます。
     また、ハイパーバイザーもAHVを利用するため、追加のハイパーバイザー費用は、かかりません。

    HCIの悪いところを克服した、Nutanixのストレージノードは、従来「NX-6035C-G5」というストレージ専用ノードとして販売されていました。
    現在では、ストレージ専用ノードは、Nutanixで販売されているどのノードでもストレージ線のようー度に設定することが出来ます。

    Nutanixが提供するFoundationツールで、イメージングの際にストレージ専用ノードのチェックを入れてイメージングをすることで、任意のノードをストレージ専用ノードとして稼動させることが出来ます。

    ▼Foundation時に特定のノードをストレージ専用ノードに設定
     ストレージ専用ノード時に設定するAHVのバージョンも指定可能(Foundation 4.5.1)

    このストレージ専用ノードのチェックは、Foundation 4.0から搭載されました。
    また、Foundation 4.5からは、ストレージ専用ノードに対してイメージングするAHVのバージョンを指定できるようになりました。(4.4までは、インストールするAOSに搭載されたAHVバージョンが自動的に展開されていました)


    Nutanixは、ユーザーが便利に、もっと言えば、ITインフラを気にしなくて良い環境を提供することが理念です。そのためHCIによってデメリットが出てくる部分において、そのデメリットを解消する技をちゃんと用意しているところが、Nutanixの魅力的なところの1つだと思います。




    2019年12月24日火曜日

    Flashモードのご紹介

    Nutanixは、AllFlashモデルやNVMeモデルもありますが、売れ筋はSSDとHDDのハイブリッドモデルです。
    Nutanixは、SSDもHDDもキャパシティ領域として利用するいわゆるティアリングでよく使われるデーターをHOTデーターとしてSSDに配置し、使うことが少ないデーターをCOLDデーターとしてHDDにおく動きを自動的に行ってくれます。

    この場合HOT、COLDの各データーはアクセスされている頻度によりますから、あまりアクセスされないデーターはCOLD扱いとなりHDD層に保存されることは理解できるかと思いますが、定期的にしかアクセスされないが、アクセスするときは高速に動作してほしいという仮想マシンも時々あるように思います。

    例えば、月初に前月の請求書を一括でPDF出力する帳票サーバーやバッチサーバーなどがそれにあたると思います。

    このような、普段は使わないけど、いざ使うときは負荷がかかるのでSSDに配置してほしいという希望を叶える機能として「Flash Mode」という機能がNutanixには存在しています。

    このFlashModeは、「ピニングモード」と記載されているドキュメントもありますが、ピニングモードは従来の名称で現在は「Flash Mode」が機能の名称となります。

    このFlashModeは、Extend Storeの25%までの領域をFlashModeで利用できる領域として利用できます。つまり、FlashModeを有効にすればかならずすべてのデーターがSSDに配置されるというわけではないことを理解しておきましょう。

    Flash Modeは、仮想マシン単位の設定の場合、Prismの仮想マシン設定画面の一番下でFlash Modeの有効か設定が可能です。

    また、Volume Groupにおいても同様にFlashModeの設定が可能です。

    このFlash Modeは仮想マシン単位であればPrism上で設定可能です。
    一方でREST APIを利用すれば、仮想ディスク単位で設定することも可能です。

    この場合、まず仮想マシンで、「Enable Flash Mode」で仮想マシン全体を、Flash Modeの設定にした後、Flash Modeの対象から外したい仮想ディスクに対してFlash Modeを無効化するという作業になります。

    なお、この作業はREST APIを利用して行います。
    APIの発行は以下の通りです。(メソッドはPUTを利用します。)
    https://CLUSTER-VIP:9440/api/nutanix/v2.0/virtual_disks/

    投入するJSONは以下の通りです
    {
      "uuid": "仮想ディスクUUID",
      "flash_mode_enabled": false
    }

    RestAPI Exploreからでも実行することが可能です。

    この命令が成功するとステータス200が帰ってきます。

    仮想ディスクごとのFlash Modeの設定状況は、Prism画面で仮想マシンを選択後、下側に表示される「Virtual Disks」で、確認することが出来ます。

    様々なディスクの接続形態で試してみましたが、デフォルトであるSCSI以外にもSATAでもIDEも関係なく、Flash Modeの設定は可能なようです。

    では、最後にFlash Modeについて注意事項を含めてお知らせします。

    • Flash Modeは、仮想マシンのライブマイグレーションには影響しません
    • HOTデーター及びCOLDデーターの分析情報をストレージコンテナ事に持っているため、Storage vMotionを行うと、Flash Modeの効果が出るようになるまで時間がかかります。頻繁にStorage vMotionを行うと、Flash Modeの恩恵は受けにくくなります。
    • ストレージの圧縮及びキャッシュレベルの重複排除には影響しません。
      ただし、キャパシティの朝服排除設定時はFlash Modeは利用しないで下さい
    • クローンされた仮想マシンは、Flash Modeの設定は保持されません。(Flash Mode無効か状態でコピーされます)
    • スナップショットからリストアされた仮想マシンは、Flash Modeの設定が保持されないため、手動で有効の設定が必要です
    • 複数モデル混在のNutanixクラスターの場合、モデルによりSSD搭載容量が異なるため、Flash Modeの動作が必ずしもどのホスト上で稼動しても一定にならない可能性があります。
    • Flash Modeを利用するためには、Nutanix Clusterに対してUltimateライセンスが必要になります。


    Flash Modeを活用しなくても、Nutanixは、SSDをキャパシティ領域として利用しているため、SSDの容量が一定以上になるまではSSD上にデーターを保存し、ハイブリッド環境であっても、オールフラッシュモデルに近いパフォーマンスを発揮します。
    そのため今回ご紹介した、Flash Modeがすべての環境下において有効な機能では無いと思いますが、仮想マシンが多く稼働する環境下で、データーベースやバッチ処理を行うサーバーなど、利用状況に寄らずハイパフォーマンスを必要とする仮想マシンに対して、一定のパフォーマンスを提供するためには、有効的な機能の1つとなるかと思います。












    2019年12月23日月曜日

    Nutanix Moveのよくある質問とポイントをご紹介

    Nutanix Moveは、すごく簡単に仮想マシンをNutanixクラスターに移行してくれるというのは、ご理解いただけたと思います。今回はNutanix Moveでよく聞かれる質問をご紹介したいと思います。

    Q.Nutanix Moveは、どういう課金方法で提供されますか?

    Nutanix Moveは、Nutanix Cluster(有償製品)を保有している場合、無償で利用することができます。Nutanix CEをご利用でNutanix Moveをご利用になりたい方もいるかと思いますが、現状Community版のNutanix Moveは提供されておりません。


    Q.Nutanix Moveで移行がサポートされないゲストOSはどうすればいいのでしょうか?

    Nutanix Moveは原則、AHVが対応しているゲストOSの大半をサポートしていますが、一部サポートされていないゲストOSやそもそもAHVが本来サポートしていないレガシーなOSをAHVで稼動させたい場合があるかも知れません。
    Nutanix Moveは、既存ゲストマシンに対して、VMware Tools/WinRM等を利用してVirt IO Driverなどの必要なものをあらかじめインストールするなど、ほぼ全自動で移行が終えられるように作られています。サポートされていないOSの場合これらの事前準備時点でエラーが出てしまい、そのままでは移行することが出来ません。
    この場合、事前にVirtI/O Driverなどの必要ドライバーを手動でインストール後、Nutanix Moveの移行時に、Preparation Modeを「Manual」に設定し、仮想ディスクのデーターだけをAHVのNutanixクラスターにデーター移行を行うことも可能です。
    出来た仮想ディスクを元に仮想マシンを作成し、あとは必要な設定を入れれば移行を完了させることが出来ます。データー転送だけ異をNutanix Moveにお任せする機能を使うだけでもファイル移動に比べて大幅に減らす事が出来ます。



    Q.Nutanix Moveの仮想アプライアンスは、AHV側に立てた方がいいのでしょうか?それとも旧環境の3Tier環境に入れれば良いのでしょうか?

    Nutanix Moveは、ネットワークを通じて既存クラスターのデーターをvSphereの場合はVADPを使って取得し、NutanixクラスターのストレージコンテナをNFSでマウントしデーターをマウントしたストレージコンテナに配置をします。
    いわゆる仮想環境におけるバックアップとおなじ考え方でデーターを取得します。
    この場合、既存3Tier環境とNutanixクラスターの間のネットワーク帯域を比較して配置するのがよいと思います。
    3Tier環境とNutanixクラスターの間が10Gのネットワークで接続されている場合、3TierでもNutanixクラスターでもどちらにMove仮想アプライアンスを立てても速度に変わりは無いと思います。一方、3Tier環境とNutanixクラスターの間が1Gで接続されている場合は、Nutanix環境に配置すれば、バックアップデーターをNutanixに配置する際は、CVMとダイレクトに通信が出来る環境になるため、高速にバックアップデーターを配置できるようになります。


    Q.Nutanix Moveを利用するにあたって注意することは何かありますか?

    ゲストOSを移行するにあたっては以下のことを確認することが大事です。
    • 対応しているハイパーバイザーのバージョンを確認
      (ESXi5.1/Hyper-V2012~)
    • 対応しているゲストOSの確認
      (既にOSメーカーがサポートを終了したOSは原則非対応)
    • VMware Toolsがインストールされていること
    • OSのAdministrator / root権限のアカウント情報がわかること
    • Windowsの場合、UACがオフになっていること
    とくに、UACが向こうになっているかのチェックは、忘れがちですがこれは無効かしておかないと、VMware Toolsなどのツール経由で必要なファイルをゲストVMに送った後、インストールスクリプトが実行されますが、そこでUACの確認画面が裏で表示され、制御ができないため、途中で処理が中断してしまいます。

    ▼ゲストVMを移行前にUACは"通知しないに"しておきましょう



    Q.vCenter Serverが存在しない単独のESXiホストの仮想マシンは移行できますか?

    Nutanix Move 3.2以降で、ESXi単独環境でvCenter Serverが存在しない環境でもNutanix Moveを利用することができます。ただし、VDDKのAPIを利用する関係からESXiのライセンスがvSphere Hypervisor(無償ライセンス)では、Moveを使った移行は対応していません。


    Q.3TierのvSphere ESXiの環境からNutanix+ESXiの環境移行で利用できないですか?(Nutanix Moveの移行先はAHVのみでしょうか?)

    Nutanix Move 3.3から、移行元vSphere(ESXi)環境から、Nutanix+ESXiの環境においても、仮想マシンの移行が出来るようになりました。従来は移行元のvSphere環境からNutanixのストレージコンテナをNFSでマウントしてストレージvMotionなどを使って、ストレージを移行することで、仮想マシンの引っ越しを実現していました。
    しかし、既存vSphere環境を触りたくない(設定変更が許されない)場合もあるかと思います。そういった場合に、Nutanix Moveを利用することで、既存のvSphereからNutanix+ESXi環境への仮想マシンの引っ越しを、短いダウンタイムで行うことが出来ます。なお、ESXiからESXiへの引っ越しとなるため、Driver等のツールの流し込みはなく仮想ディスクファイルの引っ越しのみの動作となります。


    以上、Nutanix Moveについての注意点やよくある質問をまとめました。
    Nutanix Moveは無償で提供されていますが、大変よく出来たツールだと思います。
    従来のV2Vにおけるダウンタイムに比べ圧倒的にダウンタイムを短くすることが出来ますので、仮想マシン移行の際は是非活用をおすすめします。









    2019年12月22日日曜日

    AHVへの引っ越しは、Nutanix Moveで HyperV編(その2)

    前回までに、Moveを使って仮想マシンの移行準備を行いました。
    今回は、実際に仮想マシンをAHVにマイグレーションします。

    移行前に、Hyper-V上でデスクトップにファイルを作成しておきましょう。

    では、Moveの画面にいき、仮想マシンにチェックを入れCutoverボタンをクリックします。

    カットオーバーを行うと、仮想マシンがシャットダウンされ仮想NICの接続が切断される旨が記載されています。このまま「Continue」をクリックします。

    イベントログを見ているとチェックポイント処理が行われ最終のスナップショットが送られていることが分かります。


    既に移行処理が完了していると出ていますので、Prismで確認をします。

    移行前に作成したファイルもきちんとデスクトップ上に存在しています。
    また、デバイスドライバーもきちんとVirtI/O Driverになっていることが確認できます。

    Hyper-Vであっても、vSphere同様に簡単にAHVに移行が出来ました。

    今回のポイントは、Hyper-V第2世代仮想マシンの移行ということです。
    Hyper-V第2世代の仮想マシンは、 UEFIで作成されており従来のImage Serviceを使ったVHDXの変換だけではAHV上で仮想マシンを動かすことが出来ない状況でしたが、Nutanix Moveを利用すると、UEFIのまま仮想マシンを移行させることが出来ます。
    AOS5.11から、UEFIに正式に対応しましたので、Hyper-V第2世代の仮想マシンを移行する場合は、AOS5.11移行の環境を原則用意頂くことになります。
    (AOS5.10であっても仮想マシンに対してUEFIモードで起動させることは出来ますが、原則サポータブルではありません)

    ▼第2世代の仮想マシンを移行すると、AHVの仮想マシンも自動的にUEFIに設定される。

    以上、Hyper-V環境でのNutanix Moveを使った移行方法のご紹介でした。

















    2019年12月21日土曜日

    AHVへの引っ越しは、Nutanix Moveで HyperV編(その1)

    前回までに、ESXiからAHVへの移行が簡単にかつ、ダウンタイムをかなり短く行うことが出来ることが分かりました。
    では、今回はHyper-VからAHVへの仮想マシン移行についてご紹介します。

    今回は、Nutanix Move 3.4を利用して作業を行います。
    移行元環境は、Windows Server 2012R2で、第2世代の仮想マシン対応で構成された環境にWindows Server 2012 R2をインストールした仮想マシンを移行します。

    まずは、Nutanix MoveのSourceにHyper-Vを登録します。

    すると、add the environment と表示されしばらく待ちが発生します。
    このタイミングでHyper-Vホスト側にWinRM機能を利用して、MoveのAgentがインストールされます。インストール場所は、上記のSourceを登録する際のユーザープロファイルの配下にできあがります。この環境は、Administratorで登録をしていますので、「C:\Users\Administrator\Nutanix\Move\3.4」になります。
    併せて、「move-service.exe」 が、「Nutanix Move Agent」という名前でサービスに登録されます。

    なお、Move3.2までは、このAgentが日本語版のWindowsですとうまくインストールが出来ませんでした。これは、インストール時に利用しているPowerShellのコードが日本語に対応していないことに由来していましたが、Move3.3.1以降では、問題なく日本語環境でもインストールが可能です。

    もし、Agentのインストールに失敗し、Sourceの登録に失敗した場合、Agentを手動でHyper-Vホストにインストール後、再度Source登録することで成功する可能性が高いです。
    Agentバイナリは、Moveアプライアンスにhttp経由でアクセスします。
    http://<nutanix-move-ip>/downloads/agents/move-agent-installer.exe
    ダウンロードしたバイナリを、Hyper-Vホストにインストールします。

    なお、インストール時には以下のパラメーターを入力します。
    move-agent-installer.exe -o install <nutanix-move-ip> -u Administrator
    最後のAdministratorは、サービスを起動するユーザーに紐付きますので、Administratorと書きましたが、実際には管理者権限を保有したユーザーとなります。

    なお、AgentをインストールするとWindows Firewallにて、8087番のポートが開放されるルールが追加されます。このポート番号は、MoveとAgentがやりとりするために利用され、ポート番号を変更することはできません。

    では、続いて、マイグレーションプランを作成します。

    続いてソース環境とターゲット環境のNutanixを登録します。

    続いて、移行したい仮想マシンの「+」マークをクリックし、移動対象のVMに登録します。ここで!マークが表示されます。
    この内容は、セキュアブートに関する注意事項です。
    第2世代の仮想マシンでは、カットオーバープロセス中及びカットオーバーが完了するまでは、仮想マシンのセキュアブート機能は無効になります。カットオーバープロセスが終了すると、セキュアブート機能が再び有効化されます。

    ▼Hyper-Vで第2世代仮想マシンを作成するとデフォルトでセキュアブートが有効になる

    セキュアブートは自動的に無効にされ、移行終了後にHyper-V側のソース仮想マシンは元の設定に戻りますが、セキュアブートが必要でない場合はあらかじめチェックを外しておいてもよいかと思います。なお、セキュアブートの無効化は該当の仮想マシンがパワーオフ状態の時のみ設定変更が可能です。

    続いてネットワークのマッピングを行います。
    ここで出てくるにSource Networkは、Hyper-Vホストのアダプタになります。
    割り当てるネットワークは、仮想マシンが通信したいネットワークになります。

    この画面では、vSphere同様、ゲストOSへVirt IO Driverをインストールするためのcredential情報の入力を行います。vSphereの場合同様複数の仮想マシンを一括して移行する場合、仮想マシン個別のcredential情報を入力することも可能です。

    また、Move 3.4からタイムゾーンの設定項目も追加されました。
    ここでは、「Asia/Tokyo」を選択します。

    Hyper-Vの仮想NICに付与されたMac Addressをを引き継ぐ場合は、「Retain MAC Addresses form the Source VMs.」にチェックを入れます。

    最後にサマリーを確認し、「Save and Start」をクリックします。

    これで、Hyper-Vの仮想マシンにVirtI/O Driverなど必要なモジュールが、「C:\Nutanix」に配置されます。


    Hyper-Vマネージャーで確認すると、vSphereと同様にチェックポイント(スナップショット)が順次取得されているのが分かります。


     では次回に実際に、カットオーバーを行いAHVへの移行を行ってみましょう。









    2019年12月18日水曜日

    AHVへの引っ越しは、Nutanix Moveで(その5)

    前回までに仮想マシンの移行準備は完了しました。
    では、実際に仮想マシンをマイグレートしたいと思います。

    まずは、vSphereのスナップショットを見てみましょう。
    一段階目のスナップショットは既に転送済みで、2回目以降のスナップショットが送信されています。
    ▼2回目のスナップショット

    ▼3回目のスナップショット

    このスクリーン書ととを見ると分かるようにスナップショットは10分に一度送られていますが、スナップショットが多段になってI/Oスピードの低下や仮想ディスクファイル破損を防ぐため、スナップショットは2段階までとなっており、順次古いスナップショットが新しいスナップショットを作成される際に削除されます。

    では、データーの差分がちゃんと送られているかを確認すするため、移行する前に、移行元のWindows Server 2012 R2の仮想マシンにファイルを作成してみます。

    この検証は12/1に行っておりますのでその日付と時刻をテキストファイルに書いてデスクトップに保存します。

    続いてMoveの画面で、In Progressをクリックし、Windows Server 2008 R2をCutover処理を行います。

    確認処理が走ります。

    vSphere Clientを確認すると、移行元の仮想マシンは、シャットダウンスされ最終のスナップショットが送られていることが分かります。

    移行作業が完了すると、自動的にPrism上に仮想マシンが登録され、移行された仮想マシンが自動起動します。

    Prismを見ると仮想マシンが登録され起動していることが分かります。

    仮想マシンにログインすると、先程vSphere上で作成した仮想マシンにも移行前最終で作成したテキストファイルがきちんと移行されていることが分かります。


    今回はNutanix Moveの動きと共に移行方法を紹介しましたが、ユーザー側で操作することはMoveの画面で移行元と移行先を選択するぐらいで面倒な作業無く、任意のタイミングで切り替えが出来るというのは大変便利であることがわかります。




    2019年12月17日火曜日

    AHVへの引っ越しは、Nutanix Moveで(その4)

    前回まででNutanix Moveの基本設定が終わりました。
    では実際に、Nutanix Moveを使って仮想マシンを移行の設定をご紹介します。

    まずは、Moveの管理画面の真ん中にある「Create Migration Plan」で移行の計画を作成します。


    まずは、MigrationPlan名を入力します。


    続いて、移行元のハイパーバイザーと移行先のNutanixクラスター、移行先のストレージコンテナを選択します。
    ESXiに登録されている仮想マシンの一覧が表示されます。
    移行対象にしたい仮想マシンの「+」マークをくり行くすると、右側の移行対象一覧にと登録されます。
    ここでは、ESXi5.1に登録されたWindows Server 2008R2とWindows Server 2012 R2の2台の仮想マシンを移行します。(仮想マシンインベントリ名表示がすべて入りきれていませんが、マウスポインタを当てると名称がフルで表示されます)
    選択完了後、「Next」をクリックします。

    続いて、移行先環境のVLANを選択し、Nextをクリックします。
    続いて移行の詳細設定情報が出てきます。ここから紹介するオプションは非常に重要です。

    Preparation Mode

    こちらは仮想マシンの移行方法についてです。
    Auto
    Virt I/O Driverや移行ツールを移行対象の仮想マシンに自動インストールを行います。
    Manual
    本来Autoで実行される内容を、スクリプトで表示を行います。手動で移行元仮想マシン上で指定されたスクリプトを実行することで、Autoと同じ状態にすることが出来ます。
    Mixied
    上記の2つを混在させる場合に利用

    Credentials for VMs

    こちらは、ゲストOSの管理者アカウントを入力します。
    こちらのテキストボックスに入れた場合、プランに登録されている仮想マシン一括でこのcredential情報を利用します。
    仮想マシン個別でcredential情報を入力したい場合は、「Override individual VM settings」で個別設定を行います。

    Retain MAC Address from the Source VMs.

    移行元仮想マシンのMACアドレスを維持します。
    (MoveはIPアドレスを引き継ぎますが、このチェックを入れた場合は複数NIC搭載された仮想マシンにおいてもIPアドレスの引き継ぎが正常に動作します)

    Bypass Guest Operations on Source VMs.

    このオプションにチェックを入れると、ゲストVMにDriver等の必要な情報を一切投入せず素のままの仮想マシンの仮想ディスクを移行します。(あらかじめVirt I/O Driverを移行もと仮想マシンに入れている場合などに選択)

    上記2つのオプションは、Manage Settings for Individual VMsで仮想マシン個別に設定が可能です。

    Schedule Data Seeding

    データーの移行を開始する日時を指定します。チェックを入れない場合原則プラン保存後から開始されます。


    設定が完了したら「NEXT」をクリックします。

    Nextをクリックすると、移行元仮想マシンにスクリプト等必要なファイル等が送信出来るか確認が行われます。(credential情報が間違っている場合この時点でエラーが発生します)

    vSphere Clientから見ると、VMware Toolsを経由してファイルを転送いているところが分かります。


    最後にサマリーが表示されます。
    Planを保存しこの時点での実行をしない場合は、Saveを、このままPlanをスタートする場合は「Save and Start」をクリックします。
    Planが正常にスターとするとPlan一覧が表示され、実行中の時は「In Progress」が表示されます。

    In Progressをクリックすると、進捗状態が確認出来ます。

    最初はDriverのインストールを行っていることが分かります。


    Driverインストールなどの下準備が終わるとデーターの移行が開始されます。

    vSphere上では最初にVMware Toolsを経由したファイル転送が行われていることが分かります。
    移行元仮想マシンで認証したアカウントのTempディレクトリに必要なドライバー等が送信されていることが分かります。

    Driverのインストールが終わると、スナップショットが取得され読み取り専用仮想ディスクが読み出されていることが分かります。

    スナップショットマネージャーを確認すると、Move用のスナップショットが取得されていることが分かります。

    あとは、データーの移行を待つばかりです。
    初期データー我の移行が終わると、カットオーバー(切り替え)準備完了状態になります。Cutover可能な状況になるとStatusの横に●表示が付きます。

    もうここまで来れば準備はほとんど完了しています。
    では、次回いよいよ仮想マシンの移行完了までご紹介したいと思います。