I will double check, maybe things have changed in newer versions, but last I checked the copy storage qemu option doesn't support the fancy stuff like backing images, so no need to create the template for root. I will follow up on that though.
One other caveat I think. Source format probably has to equal destination format. So you can't live migrate between RBD and qcow2, but you could between NFS and local or some other primary storage that would support the same format. On Jan 17, 2013 6:41 PM, "Edison Su" <edison...@citrix.com> wrote: > > > > -----Original Message----- > > From: Marcus Sorensen [mailto:shadow...@gmail.com] > > Sent: Wednesday, January 16, 2013 4:35 PM > > To: cloudstack-dev@incubator.apache.org > > Subject: Re: [DISCUSS] Enabling storage xenmotion on xenserver 6.1 > > > > 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, > > > Good to know, we can control the whole process in KVM. > Is the following we need to do for storage migration in kvm? > 1. create template on destination storage pool, if src root disk's > template is not downloaded into destination storage pool > 2. create volumes on destination storage pool for each volume of the > migrating VM. > 3. send storage migration command to libvirt on src kvm host. > > > 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 > > > > > > > > >
