[libvirt] QEMU's File Descriptors

[Martin Kletzander]

On Wed, Feb 25, 2015 at 04:43:15AM -0300, Christopher Pereira wrote:
>Dear Martin,
>

Hi,

please don't top-post on technical lists and convince your mailer to
wrap long lines, thank you.

>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.

>There is an issue of an IO Error after restarting a gluster volume
>and probably doing other maintenance tasks (VM will not resume) which
>probably invalidates QEMU's File Descriptors.
>

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.

>It's an old BZ.
>

Do you have the number?

>Martin Kletzander <mkletzan at redhat.com> wrote:
>
>>On Tue, Feb 24, 2015 at 09:24:51AM -0500, Stefan Berger wrote:
>>>On 02/24/2015 08:34 AM, Martin Kletzander wrote:
>>>>On Mon, Feb 23, 2015 at 06:50:46AM -0500, Stefan Berger wrote:
>>>>>Implement virCommandPassFDGetFDIndex to determine the index a given
>>>>>file descriptor will have when passed to the child process. When this
>>>>>function is called, a flag is set to prevent the reordering of the
>>>>>file descriptors.
>>>>>
>>>>>Signed-off-by: Stefan Berger <stefanb at linux.vnet.ibm.com>
>>>>>---
>>>>>src/libvirt_private.syms |  1 +
>>>>>src/util/vircommand.c    | 33 +++++++++++++++++++++++++++++++++
>>>>>src/util/vircommand.h    |  3 +++
>>>>>3 files changed, 37 insertions(+)
>>>>>
>>>>>diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
>>>>>index c156b40..aadb833 100644
>>>>>--- a/src/libvirt_private.syms
>>>>>+++ b/src/libvirt_private.syms
>>>>>@@ -1213,6 +1213,7 @@ virCommandNewArgList;
>>>>>virCommandNewArgs;
>>>>>virCommandNonblockingFDs;
>>>>>virCommandPassFD;
>>>>>+virCommandPassFDGetFDIndex;
>>>>>virCommandPassListenFDs;
>>>>>virCommandRawStatus;
>>>>>virCommandRequireHandshake;
>>>>>diff --git a/src/util/vircommand.c b/src/util/vircommand.c
>>>>>index 6527d85..2616446 100644
>>>>>--- a/src/util/vircommand.c
>>>>>+++ b/src/util/vircommand.c
>>>>>@@ -67,6 +67,7 @@ enum {
>>>>>    VIR_EXEC_RUN_SYNC   = (1 << 3),
>>>>>    VIR_EXEC_ASYNC_IO   = (1 << 4),
>>>>>    VIR_EXEC_LISTEN_FDS = (1 << 5),
>>>>>+    VIR_EXEC_FIXED_FDS  = (1 << 6),
>>>>
>>>>The descriptors shouldn't get reordered *unless* there is
>>>>VIR_EXEC_LISTEN_FDS flag added, so FIXED_FDS shouldn't be necessary.
>>>>Or is there a bug in that approach that needs fixing?
>>>
>>>Hm, it depends on the order in which APIs are called where we either
>>>need to protect against re-ordering (if we use indices) or we cannot
>>>allow indices to be used if we need to reorder them. So, actually the
>>>way the patch is, it isn't correct, either.
>>>
>>>The problem of having to prevent the reordering of file descriptors
>>>when we are building the QEMU command line with file descriptors
>>>already exists today. So maybe I could just remove this flag and the
>>>related check knowing that reordering of file descriptors and building
>>>the QEMU command line that contains file descriptor (from before the
>>>order) would not be allowed today without any of the patches I am
>>>trying to add.
>>>
>>
>>You surely and safely can.  The point behind reordering FDs was that
>>when you're using FD passing as done by systemd, those FDs passed must
>>start from number 3.  However, because we are already passing a bunch
>>of file descriptors to QEMU and other commands, we *must not* reorder
>>any file descriptors because it wouldn't work, of course.
>>
>>Martin
>>
>>--
>>libvir-list mailing list
>>libvir-list at redhat.com
>>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- 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/d7df04ec/attachment-0001.sig>