xen-orchestra icon indicating copy to clipboard operation
xen-orchestra copied to clipboard

Live migration to exisiting drive images on other host's local storage

Open freonheat opened this issue 1 year ago • 3 comments

I would like to suggest a feature I had been thinking about quite a while that I think would greatly help many users with certain use-cases. I am not sure what to call it, so I will just refer to it as "live migration to shadow copy."

Right now, it is possible to live migrate from one host's local storage to another host's local storage. This is done all the time by people to service a host, for example. Live migration is currently performed by copying an entire image of the VM to another host each time. That can take a long time, especially if the storage of the VM is large. My idea is to add an option to leave a "shadow copy" behind on the source machine, rather than just deleting it when the migration is completed. The user could then live migrate back to that original host at a later time, much much faster, by XO doing an rsync to the shadow copy, rather than having to copy everything back over again.

It would be even more flexible if it would work with any local storage location, not just the original. For example, you typically run the machine on SSD storage but also have a "shadow copy" on slower HHD storage. You could live migrate to and from the faster/slower storage, on the local or on a different host, when desired.

This feature/concept could greatly improve the time it takes to live migrate, especially multiple large guests. Of course, it comes at the expense of additional storage being reserved/used. The time it takes to live migrate to a shadow copy would, of course, depend on how much has changed since the shadow copy was created. But if it was for a short time, very little would have to updated, and it could be incredibly fast. It also would allow hosts that have multiple storage options the flexibility to migrate to/from shadow copies on slower, less expensive (but likely much larger) storage when needed, so as not to tie up the more expensive primary storage.

Thanks for your time. Comments and thoughts are welcome!

freonheat avatar Feb 16 '24 22:02 freonheat

Hi, thank you for your feature request.

Have you considered using shared storage? Using shared storage eliminates the need to copy your VDIs every time you migrate between two hosts.

MathieuRA avatar Feb 20 '24 08:02 MathieuRA

Hi, thank you for your feature request.

And thanks for the discussion! Hopefully more people will, as well.

Have you considered using shared storage? Using shared storage eliminates the need to copy your VDIs every time you migrate between two hosts.

Indeed. However, shared storage is also typically (but not always) slower, has risks of disappearing or disconnection during long periods of use, is added expense, typically uses more power, takes more physical space, increases attack vectors/surface, and has considerable added complexity (both in setup, use, and maintenance). It is great to have choices so the user can decide which type (or types) of storage options are best and under what circumstances.

My suggestion of migrating to existing images gives yet another option, further enhancing the system and user experience. It isn't necessarily a replacement for shared storage or hyperconvergence (creating a shared storage from local storage, something I believe is still lacking and not open or stable yet). Plus, besides being very useful, I think the concept is readily understood and maybe not difficult to implement (hard for me to speculate on that).

freonheat avatar Feb 20 '24 12:02 freonheat

All right. We will discuss about this feature request with the entire XO team. We will get back to you when we have news on this subject. Thank you!

MathieuRA avatar Feb 20 '24 16:02 MathieuRA