If you are using extensively the Storage XenMotion feature in XenServer, you probably encountered some limitations.
Let's recap first what is XenServer Storage XenMotion and then a limitation you can discover while using it.
Storage XenMotion: definition
What is exactly "Storage XenMotion" in XenServer? Well, it's the ability to move a VM within it's storage in live, without service interruption, even between hosts sharing nothing.
- adopting a new SAN (just move the VM disks to it)
- migrate VMs between hosts without shared storage
- migrate VMs between different pools
As you can see, that's more than very convenient in a lot of cases. So what's the big deal?
Maximal number of concurrent migrations
Imagine you want to migrate all your VMs on another pool. Let's say 6 VMs. Today, with XenCenter or
xe, you need to do it manually for each of them (painful if you have e.g 20 VMs!).
You could already do that with Xen Orchestra:
Selecting 6 VMs at once and migrate them to another host ("Lab3" here)
But only 3 will actually migrate, because XenServer has a built-in limit: no more than 3 Storage XenMotion at once on the same destination.
Let's see the solution!
Solution: a migration queue
To keep our example with 6 VMs, when we start to migrate all the VMs at once, we got an error from the API of XenServer (XAPI):
Now, to avoid manually migrate VMs 3 per 3, we catch this exception for each failed VM, and we try again seconds later. This way, as soon one of the migration is finished, the next VM asking to migrate will pass. Until every VMs made it!
You can now migrate using Storage XenMotion any number of VMs, and just let the process finish itself!