[libvirt] QEMU's File Descriptors

[Martin Kletzander]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150225/d52a7c28/attachment-0001.sig>