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

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.