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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> --- 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
Attachment:
pgpLNSqVNtwxH.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list