none
Migrating CSVs to different storage without SCVMM and without exporting VMs

    Question

  • Hi.  We have a 2-node 2008 R2 hyper-v cluster using two CSVs and MD3000 SAS storage.  We are replacing the storage (going to a SAN), so we need to move the VMs from the current CSVs onto the new ones.  I read about SCVMM Quick Storage Migration feature, but we don't have SCVMM.

    We already created the two new CSVs and added them to the cluster, so we could export each VM onto the new CSVs, but that would take a while.  Each VM has multiple VHDs, too, and some of them live on CSV1 and others on CSV2.  So it could be painful to do this VM-by-VM.

    But, what if we do this:

    1. Shutdown all VMs (some overnight downtime is acceptable in our case)
    2. Copy all data AS-IS underneath c:\ClusterStorage\volume1 and c:\ClusterStorage\volume2 to the new CSVs (let's call them \volume3 and \volume4)
    3. Rename volume1 and volume2 to something different
    4. Rename volume3 and volume4 to "volume1" and "volume2"
    5. Start all VMs

    Would that cause any problems?  In theory, all VMs' configs are told to point to VHDs located on C:\ClusterStorage\Volume1 and Volume2, so technically, that will still be the case.  But I don't know if this would cause any other problems.

    Any advice?  Thanks.

    Wednesday, March 14, 2012 9:18 PM

Answers

  • Hi,
     
    If there isn’t SCVMM in your environment, the easiest way should be use export/import.
     
    If you right click on the virtual machine folder, you will be able to find some special account in Security tab. Just copy the virtual machine to a new volume does not take care the security settings.
     
    By the way, if you can copy the virtual machine folders, why not just perform an export?
     

    Vincent Hu

    TechNet Community Support

    Thursday, March 15, 2012 1:46 AM
    Moderator
  • Quick update:  just performed xcopy according to these instructions and it appears to have copied all ACLs.  Proceeded to rename the CSV volumes.  Started the VM, and it seems to have worked.

    So unless there is anything else to worry about, this appears to be a viable method.

    On a sidenote.... We decided to look into getting SCVMM, as it would handle this job even better, plus it would help us manage VMs anyways.

    Thursday, March 15, 2012 3:25 PM

All replies

  • Hi,
     
    If there isn’t SCVMM in your environment, the easiest way should be use export/import.
     
    If you right click on the virtual machine folder, you will be able to find some special account in Security tab. Just copy the virtual machine to a new volume does not take care the security settings.
     
    By the way, if you can copy the virtual machine folders, why not just perform an export?
     

    Vincent Hu

    TechNet Community Support

    Thursday, March 15, 2012 1:46 AM
    Moderator
  • Hi,
     
    By the way, in Windows Server 8, you will be able to perform a live storage migration.
     
    For more information, you can refer to:
     
     
     

    Vincent Hu

    TechNet Community Support

    Thursday, March 15, 2012 5:29 AM
    Moderator
  • Thanks Vincent.  Good to know that about Windows Server 8.

    So, the only reason I was trying to get away from exporting and reimporting every VM is because it's a manual process requiring me to hit each VM individually.  Whereas, if I copy all subfolders on CSV1 and 2 and put them on CSV3 and 4, I would be done in a couple of simple steps (after the copy process completes, of course).

    Is the permissions issue the only issue with this approach?  What if I copy the folders along with ACLs (using xcopy or somthing like that)?

    Thursday, March 15, 2012 2:18 PM
  • Quick update:  just performed xcopy according to these instructions and it appears to have copied all ACLs.  Proceeded to rename the CSV volumes.  Started the VM, and it seems to have worked.

    So unless there is anything else to worry about, this appears to be a viable method.

    On a sidenote.... We decided to look into getting SCVMM, as it would handle this job even better, plus it would help us manage VMs anyways.

    Thursday, March 15, 2012 3:25 PM
  • You can copy all the files (VHDs) from under the VM to the new storage.

    And then just modify the settings of the VM to point to the new disk.

    This takes just as long as an Export / Import (in the end) - but does work.

    If you have any snapshots - do Export / Import otherwise you need to modify each differencing disk or they will work but use the origional - it will all work until you remove the origional storage and then suddenly broken.


    Brian Ehlert (hopefully you have found this useful)
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Thursday, March 15, 2012 3:44 PM
  • You can copy all the files (VHDs) from under the VM to the new storage.

    And then just modify the settings of the VM to point to the new disk.

    This takes just as long as an Export / Import (in the end) - but does work.

    Brian, this is what I was trying to avoid by renaming the CSV volumes.  If I copy the files (VHDs + config files and all for each VM), then just rename the CSVs (see original post at the top), then I wouldn't have to modify the settings to point to the new disk, thus speeding up the process.  Since we want to move all VMs completely from one CSV to another, we can get away with renaming the CSVs.  But my concern was whether this approach has any gotchas.  And one is apparently this issue with permissions, unless you copy that over as well--which seems possible with xcopy (probably with robocopy too).

    We don't have any snapshots, I don't think, but good to know that those could be problematic.

    Like I said,m in the end, we might do this with SCVMM if we end up getting it... But I definitely wanted to know the manual options, too.

    Thursday, March 15, 2012 3:52 PM
  • The hitchy part is that you can't just copy the config - not until Win8 as it is part of the Move process.

    Under the hood are Literal Paths and reference pointers. There is no spoofing here.  There are no configuration files like Virtual Server, VirtualPC or VMware had (well they don't work that way until Win8).

    If you are not going to crack open the settings of each VM you would most likely flow like this: copy (including ACLs), shut down all VMs, change the letter of the origional LUN, make the new LUN the drive letter of the origional, restart the VMM Service, try to power on a VM.

    It is that config part that I don't know about, the disks is easy to fix, the config part - not so much.

    You would need to try it all and see what happens to really know.


    Brian Ehlert (hopefully you have found this useful)
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

    Thursday, March 15, 2012 4:29 PM