[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/2] qemu: Clear source path of removable block if it is ejected.



于 2011年08月12日 21:04, Daniel P. Berrange 写道:
On Fri, Aug 12, 2011 at 09:34:42PM +0800, Osier Yang wrote:
This patch is mainly to solve the migration problem:
   After the media is ejected inside guest, and one removes the
source of the media outside, migration will fail early, as we
start the qemu daemon on dest host with the source of the removable
block still existing, this causes failure when trying to do cgroup
setting on the media source then.

   All the migration functions try to get the domain XML before
doing preparation on dest host. Except one specify the domain
XML externally (e.g. option "--xml" of "virsh migrate"). So this
patch changes the function "qemuDomainFormatXML" to check the
media status of removable block using the new introduced monitor
functions, and clear the source path if the media ejected, so
that it won't start the qemu daemon on dest host along with the
media path.

   Public migration APIs invokes "driver->domainGetXMLDesc";
"driver->domainMigratePeer2Peer" uses "qemuDomainFormatXML"
for v2 migration protocol and "qemuDomainBegin" for v3 migration
protocol, to get the domain XML before preparation on dest host.
All of these 3 functions are based on "qemuDomainFormatXML", that's
why making changes on it.

   The changes affect the running domain config, (e.g. for a running
domain, "virsh dumpxml" won't display the source path of the media
anymore once it's ejected inside guest. But think it's reasonable
to do like so.
No, IMHO, we really do not want to be going to the QEMU monitor every
time we dump XML. We want the dump XML operation to be fast&  reliable
even in the face of a stuck/deadlocked QEMU [1].

If we want Dump XML to always show the corect state, then we need
QEMU to be giving us an event notification.


Daniel

[1] Yes we have a problem with the balloon query update in this respect
     too, but we need to fix that, not make the problem worse.

Agree, but there is no better idea in my mind to solve the migration problem with
"info block" but no qemu event.

Both the public migration APIs and the internal qemu migration APIs need to get the domain XML before doing preparation on dest host, all of them need a way to
let the dest known if the disk is ejected. That's why I choosed to change
"qemuDomainFormatXML".

Or do you have any good idea? Thanks

Osier


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]