Moving VM (.vhd) manually on different Hardware - Best Practice ?

Answered Moving VM (.vhd) manually on different Hardware - Best Practice ?

  • Friday, January 07, 2011 10:00 AM
     
     

    Hello,

    i have some Hyper-V Servers 2008 R2 with VMs inside.

    I will have to move some VM to another server with different hardware (xeon 51xx series to 54xx series or 55xx).

    i was wondering if i need to sysrep my VM before to move it manually (i mean, i don't use any live or quick migration from SCVMM 2008 R2).

     

    i will just create new VM on my new Hyper-v server 2008R2 and use .vhd that i had backuped from the old Hyperv server.

     

    Or maybe it will be "cleaner" to use "Export VM" and "Import VM" to the new hypervisor ?

    What's the best practice to move VMs manualy without getting troubles ?

     

    Best Regards,

     

    Marc.

     

All Replies

  • Friday, January 07, 2011 10:07 AM
     
     Answered

    You got CPU from the same manufactural  - thats good.

    If you export the VMs, you will include everything. configuration, vhd, and also even avhd if using snapshots.

    You do not mention what kind of VMs you run (like Domain Controllers etc).

    But in general, the Export/import is well suited when you would like to move your VMs without using shared storage with Failover Cluster etc.

    Some information about import/export in Hyper-V: http://kristiannese.blogspot.com/2010/12/things-you-should-know-about-import-and.html

    Another scenario would be to only move the .vhd files, re-create the VMs on the new server, and attach their vhd`s.

    Regards, 


    Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
  • Friday, January 07, 2011 10:40 AM
    Moderator
     
     Answered

    Hi,

     

    The following post discussed a similar issue, you can refer to:

     

    Move VM to a new server with a different cpu (AMD)

    http://social.technet.microsoft.com/Forums/en/winserverhyperv/thread/5458918c-ecfd-49ea-b7ec-470911358648

     

     

    Best Regards,

    Vincent Hu

     

  • Friday, January 07, 2011 11:31 AM
     
     

    Ok, thanks Both, some good infos,

     

    i guess since i'm still on Intel Xeon 5xxx series platorm it will be ok, to use Export and Import VM to the new hypervisor..looks it's the best way, even though create new VM and use .vhd file will be working, since by the way, i generaly backup only my vhd's.

    to answer you Kristian, the VM i want to move especially, is a DC with AD, and SCCM 2007R3 (and all roles that coming with it : WSUS, IIS..etc)...that why i don't want to have to  sysprep it ;D

     

    i guess there is some check to do , in the hadware configuration of the VMs after importation in the new hypervisor (number of processor, ram, and especially virtual switch used..)?

     

    Regards,

    Marc.

     

  • Friday, January 07, 2011 11:38 AM
     
     Answered

    The export should - as I said - include everythin in the VM. Just be sure to power off your VMs before exporting.

    The configuration of the VMs should be identical after import - since everything is included in the export.

    I`ve used this procedure often when moving VMs between hosts withouth using Failover Clustering with success, and it`s the rigth way to do it.

    Regards, 


    Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
  • Friday, January 07, 2011 12:20 PM
     
     

    Ok Thanks Kristian,

    Regards,

  • Friday, January 07, 2011 1:11 PM
    Moderator
     
     

    Hi,

     

    Do not use the Hyper-V Export feature to export a virtual machine that is running a domain controller.

     

    For more information, you can refer to:

     

    Deployment Considerations for Virtualized Domain Controllers

    http://technet.microsoft.com/en-us/library/dd348449(WS.10).aspx

     

     

    Best Regards,

    Vincent Hu

     

  • Friday, January 07, 2011 1:26 PM
     
     

    In general, that`s Microsoft recommendations. But I have never encountered any issues when exporting the DC VM from host A to host B, as long as the VM on host A never comes online again. I guess that`s why you want to move the DC VM - to use it on host B, and not as a clone.

    From that perspective, I cant see how there would be a USN rollback on a DC that is exported and imported. Exporting a VM does not change the SID etc. since the VM is powered off before export. Everything is included with the export, so I cant see how it should create USN rollback etc.

    I have never had issues with this - at all, with this procedure.

    Regards, 


    Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
  • Friday, January 07, 2011 2:40 PM
     
     

    hum interesting,

     

    they did not say exaclty why Export can't be used. Indeed, if you DUPLICATE your DC, that not advised, but if you move the VMs, i don't know why it's not advised, even though there is no snapshot with the VM.

    I would like to know the technical reason to why we can't export VM that is a DC :)

     

     

  • Friday, January 07, 2011 3:32 PM
     
     Proposed

    As I mentioned in my last reply - there is no technical issues with exporting and import a vm dc. But if you start both machines afterwards, you would have problems. But if you could not export/import vm dcs, how could you actually move a vm dc then? You couldn't. You can even run a P2V on dc, as long as it is an offline conversion. Key word in both terms: dont start both machines. So you could export and import your vm dc, but not for cloning, only moving.

    Regards,


    Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
  • Friday, January 07, 2011 3:41 PM
     
     
    yep i agree with that!
  • Friday, January 07, 2011 3:44 PM
    Moderator
     
     Proposed

    Personally I do not understnad the MSFT statement of not Exporting a Domain Controller.

    The only reason that I could possibly think of is that there is a possibility that the virtual NIC device might change and thus any manual network configuration is lost.

    The only way that I know that this virutal NIC device is maintained is if the VM is Live Migrated - and that can not happen if the hardware is different as the new macahine would not be allowed into the cluster.

    In my mind this statement is a catch all and may have a valid basis but over-all has many cases thhat make it invalid.

    The absolute safest way to move a domain controller is to power it down, cleanly.  And in doing this Live Migration is not possible.

    And, if you are moving the VM to different hardware (with distinctly different CPUs) then you MUST power off the VM and Live Migration is not an option.

    Cloning a domain controller is a totally different issue - that has its own mess of special cases.

     


    Brian Ehlert (hopefully you have found this useful) http://ITProctology.blogspot.com
  • Monday, January 10, 2011 7:19 AM
     
     
    Any update on this? Have you tried the suggestions?
    Kristian (Virtualization and some coffee: http://kristiannese.blogspot.com )
  • Monday, January 10, 2011 3:58 PM
     
     

    still not, my new hardware is still not ready !

     

    but a will do it, i will tell you if it 'll works ! stay tuned ;-)