On 04/16/2012 03:03 AM, Paolo Bonzini wrote: > Il 14/04/2012 00:32, Eric Blake ha scritto: >> But if the world conspires against me, such as libvirt going down, then >> qemu completing the reopen, then the guest VM halting itself so that the >> qemu process goes away, all before libvirt restarts, then I'm stuck >> figuring out whether qemu finished the job (so that when I restart the >> guest, I want to pivot the filename) or failed the job (so that when I >> restart the guest, I want to revert to the source). To do this, I now >> have to create a new file on disk (not a pipe), pass in the fd in >> advance, and then call drive-reopen, as well as record that filename as >> the location where I will look as part of trying to re-establish >> connections with the guest when libvirtd restarts. > > Yes. > >> I'm not quite sure how to expose this to upper-layer management >> applications when they are using libvirt transient guests, but that's >> not qemu's problem. > > Do transient guests have persistent storage for them in /var while they > are running?
Yes - that's how libvirt tracks the pid of the qemu process that it should be re-attaching to on a libvirtd restart, as well as several other aspects (for example, the capabilities of the qemu binary running that pid, in case qemu has been upgraded in the meantime). It's just that right now, the files that libvirt stores in /var are intended to be internal to libvirt, so management apps shouldn't be poking around in there, so much as having an interface to ask libvirt what state things are in. >> Question - I know that 'drive-reopen' forces a block_job_cancel_sync() >> call before closing the source; how long can that take? > > Not much; the mirroring job polls the dirty bitmap for new I/O every 100 > ms, so it should be more or less comparable with the bdrv_drain_all that > is also performed by drive-reopen and blockdev-snapshot-sync. > >> So that does mean that a call to 'drive-reopen' could indeed >> take a very long time from initially sending the monitor command before >> I finally get a response of success or failure, and that while the >> response will be accurate, the whole intent of this patch is that >> libvirt might not be around to get the response, so we want something a >> bit more persistent. Does this mean that if we add 'drive-reopen' to >> 'transaction', that transaction will be forced to wait for >> block_job_cancel_sync? > > Transactions are already waiting for pending I/O to complete > (bdrv_drain_all), and mirroring that I/O to the target > (block_job_cancel_sync) won't take much longer. In other words, 'block-job-cancel' (and commands built on top of it, like 'drive-reopen') isn't instantaneous, but also is still easily in the sub-second range. Good to know. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
