The main blocker for KVM is that you can't start the vm with the -snapshot command (which is a way to start a vm with a base image and use a temp file for any changes, more of a temporary VM). Also, if you storage migrate a qcow2 image (or any sparse file), it gets fattened in the copy. Which is bad, but people may still prefer the option to be able to migrate. For those of us using luns on a SAN or something like that though it will be business as usual, both clusters see the storage, VM hops from one host to the next.
It actually works almost identically to the existing migrate, with the additions that identical new storage needs to be set up on the destination, and an extra flag set in the migrate command. I'm not sure about RBD support, but I'm assuming it works so long as the storage is available (Wido? Can you see me waving my hand?), I bring that one up because it's the one I'm aware of that is baked into qemu where it speaks to the storage directly through librados, rather than using some sort of block device or filesystem that the host is aware of. I think this partially goes with the zone-wide primary storage. In that case there's no longer the need to storage migrate in the case of moving between clusters. As far as orchestration, I'll have to read through the other hypervisor requirements, but on the KVM side the storage migration is triggered via the agent (via libvirt). If I remember correctly there's a portion of the cs server that preps the destination host (passing PrepareForMigrationCommand) and then one that triggers the migration on the source host (passing MigrateCommand). We'd just add to those sections in the server to create any volumes necessary on the destination storage first, along with the nic/network prep it already does. Then on the source host it does a MigrateCommand with the libvirt flag to copy storage (VIR_MIGRATE_NON_SHARED_DISK in the libvirt API, passed along to virDomainMigrate). I actually think it could be added to migrateVirtualMachine without too much effort, just adding optional parameters "clusterid" and boolean "copystorage". That would make it flexible enough to copy local storage between hosts by providing a hostid and the copystorage=1, as well as migration between clusters. That's what I'd do if we only had to deal with KVM anyway, it might make sense to do something entirely different if that isn't sufficiently hypervisor agnostic. On Wed, Jan 16, 2013 at 2:46 PM, Alex Huang <alex.hu...@citrix.com> wrote: > Marcus, > > Nice. Can you take it for the KVM resource then? Do you have any > comments on the orchestration flow of this? > > --Alex > > > -----Original Message----- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Wednesday, January 16, 2013 1:33 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: [DISCUSS] Enabling storage xenmotion on xenserver 6.1 > > > > We want this for KVM as well. libvirt has been able to do a storage copy > > along with a live migrate for awhile now, so it's just a matter of making > > sure that the implementation is compatible so we can plumb in the libvirt > > stuff. > > > > On Wed, Jan 16, 2013 at 9:35 AM, Chris Sears > > <chris.x.se...@sungard.com>wrote: > > > > > On Wed, Jan 16, 2013 at 11:07 AM, Koushik Das <koushik....@citrix.com > > > >wrote: > > > > > > > Looks like storage vmotion is not possible for VMs with linked clone. > > > > Check this KB > > > > > > > > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&; > > cmd=displayKC&externalId=1014249 > > > . > > > > This is for 4.x, not sure if the latest version supports it. > > > > > > > > > > That is no longer a limitation in versions 5.x of vSphere. VMs with > > > snapshots and linked clones can be storage vMotioned. > > > > > > Mentioned here: > > > > > > http://blogs.vmware.com/vsphere/2011/07/new-vsphere-50-storage- > > features-part-2-storage-vmotion.html > > > > > > - Chris > > > >
