On 11/08/2012 07:57 PM, li guang wrote:
> What if you want to offline migrate a domain that is currently
running?
> I think it's better to first move qemuDomainCheckEjectableMedia down to
> qemuMigrationBegin in a separate patch and then just use the code from
> v12 (without using the offline label).
sorry, I don't like to do offline migrate for a domain that's running.
Why not, when we've already argued it can be useful? You don't have to
support it in the same patch, but you should at least take the advice on
how to refactor things so that someone else that does like the idea can
extend things to provide it. There's nothing wrong with having
persistent definitions of the same domain on more than one machine, as
long as only one machine at a time is running it; and after all, with
live migration, if you _don't_ pass the --undefinesource flag, you will
be left in the same situation where a persistent domain on the source is
left behind even when the running domain has migrated.
>
> Oh, I'm sorry for not noticing this earlier, but why exactly do we need
> this <offline/> element in migration cookie? It doesn't look like we need
to
> store some additional data required for offline migration. I think just
> passing the VIR_MIGRATE_OFFLINE flag will be better. Not to mention that if an older
> libvirt gets a cookie with <offline/> element, it will just ignore it
> while passing a flag (which the code should already been doing anyway) should
> make it fail for unsupported flag.
without this how do you know you a offline migration at target side?
By the presence or absence of the flag. If the flag is present, you are
doing an offline migration. I agree that we don't need to add anything
to the cookie, since the only way to get offline migration is via the
new flag, and both source and destination will see the same set of flags.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org