Migrating VMs between different storage classifications
-
Friday, April 27, 2012 5:48 PM
A bit of background. Our company uses several Hyper-V configurations as far as storage is concerned:
- EqualLogic storage connected to single hosts
- EqualLogic storage connected to clustered hosts (CSVs)
- Compellent storage connected to single hosts
- Local storageIn VMM 2008 we had no issues using network migrations regardless of what the storage was. We could migrate between EQL and Compellent, between EQL and Standalone, etc.
In VMM 2012 we have noticed that we can and cannot migrate depending on direction and storage type
- FROM EQL cluster to ANY standalone (Compellent, local, EQL) - WORKS (so long as you uncheck live capable hosts)
- FROM EQL standalone to Compellent standalone or local - FAILS
- FROM Compellent to ANYTHING else - FAILS
- FROM local to ANYTHING else - WORKS
- Provided we have the space, FROM anything to "storage migration" > local storage on same host WORKS. We can then migrate anywhere else, since local to any works.
Regarding the failures, the message we get is: "The host does not have access to sufficient storage of the requested classification for one or more virtual disks associated with virtual machine XXXX".
I do have the Compellent classified, but it appears we also have issues moving between generic classifications (local/remote storage). Right now the only way to get around this is to either move something to an EQL cluster if it was on EQL standalone, or perform a storage migration from the Compellent to local storage so that we can turn around and migrate it to either another host on local, or EQL clustered. This is extremely frustrating, as we don't generally run only one VM per LUN anyway, so we don't make use of SAN migrations, and they wouldn't be available on the EQL hosts even if we did use single LUNs since EqualLogic is not a compatible vendor (if they were, I'd add the storage into the same classification to get around this, at least for situations other than SAN to local).
Does anyone know of a way to modify this behavior? Is it expected? I just want to perform network transfers regardless of the storage type used, like we could in the older versions of VMM.
Thanks,
Aaron
All Replies
-
Thursday, May 03, 2012 4:12 PM
It's been a week with no replies, so I thought I'd try a shameless bump. This will be the only one until I give up on getting an answer here (if nobody replies again), I promise.
Aaron -
Wednesday, May 23, 2012 2:41 AM
Storage classification includes local storage, remote storage and customized classfication.
- For network transfer, VMM 2012 supports to migrate a VM with classification1 to destination machine which at least has one storage belong to the classfication1. It's VMM behavior.
- For EQL SAN migration, you can use EqualLogic Hardware VDS provider for SAN in the older version before VMM 2012 SP1. And EQL array also will be compatible with SMI-S provider in VMM 2012 SP1.
-
Wednesday, May 23, 2012 3:15 AM
Benny,
Thanks, but I'm unsure how your post helps. I understand the behavior of VMM, but I want to be able to classify generic remote storage or local storage as the same tier as the Compellent storage so that I may migrate. To say that requiring use of a storage classification compatible with the one you're migrating to and from is VMM behavior is pretty obvious, as that was the error I recieved. I basically am looking to modify the behavior. I did hear some Compellent/Dell reps saying that something was coming this summer to allow EQL to be classified, and when that happens it will indeed correct part of the issue. I still find it pretty insane that VMM 2012 will not let you migrate from classified storage to generic storage if you don't have things configured in a way where you could use a SAN migration anyway (more than one VM per LUN) and where you don't use rapid provisioning for VMs, but that's looking to be the case.
- Edited by Aaron-SRS Wednesday, May 23, 2012 3:17 AM
-
Tuesday, August 21, 2012 7:52 PM
I'm running into the same issue. My scenario:
Cluster1 - Equallogic CSV, classified in VMM as "Remote Storage"
Cluster 2 - NetApp 2040, managed in VMM using SMIS and classified using custom classifications (Gold, Silver)
When I attempt to migrate VMs from Cluster1 to Cluster2, I am unable to do so, receiving the validation error "The host does not have access to sufficient storage of the requested classification for one or more virtual disks associated with virtual machine XXXX" as indicated above. However, if I uncheck the high availability option in the validation page, I can migrate directly to local storage on either of the nodes in Cluster2.
Does anyone know where this is documented? Why can't I migrate between clusters managed by VMM 2012? Or is there a configuration needed to enable this?
Thanks,
Noah
-
Monday, September 10, 2012 9:57 PM
At least I am not the only person being angered by this new restriction when compared to older VMM versions. We have 1 server setup with an iSCSI LUN for extra storage and any of the VM's sitting on that cannot move to our other server with just local storage.
Very frustrating!
-
Tuesday, October 16, 2012 11:07 AM
Same issue here. We use a few dedicated hosts machines storage to create the images before they go into the high availability pool on the nas storage.
The workaround we currently use is cloning the image (then the classification is ignored) and then removing the original :(
-
Thursday, October 18, 2012 5:52 PM
Same issue here. We have hosts with local disks and hosts that connect via fiber to a SAN (SAN is not managed through VMM). The servers with local disks have classification listed as 'local storage', while the disks connecting to the SAN have their disks classified as 'remote storage'.
Unfortunately there doesn't seem to be a way to migrate VMs directly between the two (using network migration of course). I will try the clone approach as mentioned by Rolf, but that solution is not ideal for obvious reasons.
Cheers,
Max
-
Friday, October 19, 2012 9:14 PM
I am experiencing this same issue with VMM 2012.
Here's a twist:
I am migrating from a host with iSCSI SAN to a host with local Storage
Three Migrations have been performed flawlessly - I have three more migrations to perform and am now getting this error.
I do not have Storage classifications set in VMM
-
Sunday, October 21, 2012 7:53 AM
Hi, Aaron
when you created the VM template for VM , have you specified a storage classification for you VHD files ? in the VM hardware tab? what was it ?
what classification do you have ? how are they assigned to storage devices ?
Regards, Hikmat Kanaan Amman-Jordan Remember to click “Mark as Answer” on the posts that helps you
-
Monday, October 22, 2012 4:21 PM
Hikmat,
Looking at the templates, the classification section is blank. On running and stopped VMs there is a classification in most cases (sometimes on EQL storage in a cluster config this isn't true). This classification is greyed out, including when a VM is stopped, and I don't see a way to change it. There are generic classifications of "Remote Storage" and "Local Storage". We also did classify our Compellent SANs, and those named classifications pop up when a VM is placed on host attached to such SANs. These VMs classified themselves when they were created rather than having classified templates.
I've before listed that we have problems even between generic auto classified storage, and we definitely see problems with our purposefully classified storage as well. I'd understand a warning or even something requiring an override when changing classifications; I just don't like having no override options, especially given we don't use any special features that classification gives us (mainly because when we tried things like having one VM per lun and then being able to migrate without windows clustering/CSVs, there were a lot of problems).
Also, we at one point did remove all existing classifications/pools/arrays/providers which we created from VMM to no avail.
-
Monday, October 22, 2012 5:33 PM
Quick update on our end. I've found 3 ways to work around this issue (they are all a pain in the butt, but get the job done):
Quick note here - For some reason this issue only manifests itself when the servers are not clustered. We are able to move VMs from local storage to the clustered storage (CSV shared by 4 hyperV nodes) without problems. The issue only occurs when we are migrating VMs from Local Storage (non-clustered) to Remote Storage (nonclustered), or from Remote Storage (non-clustered) to Local Storage (non-clustered).
Either:
1. Store a VM in the library and then deploy to the server with different storage classification
or
2. Clone the VM to the server with different storage classification and then delete the original (this was suggested by Rolf above).
or
3. Move the VM to our Hyper-V cluster first and then move it over to the server with different storage classification.
or
4. Export VM from HyperV host (not from VMM2012 console), manually copy the VM export to the new server and then Import there.
As stated, all of these methods (except number 4, which sucks as we don;'t get to use VMM console at all) essentially involve copying the VM twice, so they are not ideal, but they seem to work for us.
I'm hoping someone from MS would see this thread and chime in on this VM migration process behavior. Also, we are running CU2 for VMM 2012. Can someone confirm if they are getting the same issue with VMM 2012 RTM? I seem to remember us moving VMs between the problem hosts without any issues in VMM 2012 RTM, but i can't remember/confirm the exact details as we have re-shuffled our vritual resources several times since the introduction of VMM 2012.
Cheers,
Max
- Edited by Maxim M Monday, October 22, 2012 5:33 PM
-
Monday, October 22, 2012 5:39 PM
Maxim,
I can confirm that this did occur with the RTM. I started this thread on April 27th, and installed CU1 on May 3rd. Thanks for the workaround list, and I also keep hoping for an answer from Microsoft on this, with a newly minted hotfix or something along those lines. Anyway, I've taken to method 2 since Rolf suggested it.
Aaron B
-
Monday, October 22, 2012 5:53 PM
I could have sworn I got this work around from here, but just did a quick re-read and I must have found it somewhere else, cause I do not see my work around listed.
To be clear, my issue was with moving from "remote storage" to "local storage". I have heard that "local storage" to anything works and so far haven't hit a wall moving from local.
My work around is as follows:
1. Use the Migrate Storage (NOT Migrate VM) wizard to move the VHD to "local storage"
2. Use the Migrate VM wizard to move the VM to the new host where you actually want it.
Still involves moving the VM twice, but the first move there is next to no downtime as the move is all happening on the same server and working memory doesn't need to be moved. Of course this requires enough local storage on the host you are trying to move from.
-
Monday, October 22, 2012 5:56 PM
Jeefrd,
I think you got that from my original post:
"
- FROM local to ANYTHING else - WORKS
- Provided we have the space, FROM anything to "storage migration" > local storage on same host WORKS. We can then migrate anywhere else, since local to any works."
:)
We have issues with that though because a lot of our VMs are huge.
- Edited by Aaron-SRS Monday, October 22, 2012 5:57 PM
-
Monday, October 22, 2012 7:38 PMAhh yes I see that now. When I re-read the thread to see where I got that from, I must have skipped the OP.
-
Friday, October 26, 2012 1:33 PMNoah - I got the same error and found that local Hyper-V was set to place VMInstance files on the C drive - VMM sees this as the location for your migration even if you choose a drive that has plenty of space on it - when I set Hyper-V server to defualt to storage drives instead of the default location, this got rid of the 'sufficient storage space' error.
good luck!
.png)
