On Wed, Feb 25, 2015 at 06:08:04AM -0300, Christopher Pereira wrote:
Does libvirt currently reopen image files when resuming a VM?We might probe them, but that's it for now from what I know. QEMU opens its file descriptors for them. We are passing FDs now for tap network interface and similar, not for disks.Yes. If we pass file descriptors, we may want to probe and reopen them to make the whole solution robust.
As I said I'm no glusterfs guru, but if qemu uses libgfapi, can't that do the job? Ideally transparently?
I have no idea what gluster does under the hood, but if it messes up QEMU, then it's most probably not libvirt's fault. We can't be 100% fool-proof and whatever-proof.Let's suppose that our image files are on a folder that gets remounted and QEMU's file descriptors go into a bad state (still an hypothesis).
Well, if somebody (who remounted the FS, be it user or mgmt app) knows about it, it might be nice to get that notification down the stack, so we're not reopening everything all the time.
If we are passing file descriptors (disk and network) we may need to reopen them in libvirt.
We're not and we won't be for some time IMHO.
If we are passing paths and sending QEMU something like a "resume" command, then QEMU should reopen them.
And it could be done automatically for each bad FD, just not for each and every one.
Do you have the number?https://bugzilla.redhat.com/show_bug.cgi?id=1058300
This might be worth asking about in qemu-discuss or qemu-devel if nobody responds to that BZ in a while.
I didn't have the link before, since I wrote from my Android (UTC-4). Best regards.
Attachment:
pgpObatnXANH1.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list