qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: "MATSUDA, Daiki" <matsudadik@intellilink.co.jp>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [BUG] qemu-ga: failed to fsfreeze-thaw on RHEL 5.8 Guest
Date: Sun, 27 May 2012 19:49:28 -0500	[thread overview]
Message-ID: <20120528004928.GF5615@illuin> (raw)
In-Reply-To: <4FC2B4CC.8090505@intellilink.co.jp>

On Mon, May 28, 2012 at 08:12:12AM +0900, MATSUDA, Daiki wrote:
> I researched the source of the bug.
> 
> qemu-ga calls guest_fsfreeze_build_mount_list from
> qemp_guest_fsreeze_thaw in qga/commands-posix.c. And it tries to read
> /etc/mtab (= MOUNTED) to get mounted filesystems. But when they are
> frozen, getmntent(fp) is not finished in the situation /etc/mtab in
> frozen filesystem.
> 
> I suggest to read the list from not frozen filesystem file or on-memory
> data, e.g. /proc/mounts.

Yikes, this is a scary bug. Thanks for catching this.

I suspect the getmntent() call is causing an access time update to
/etc/mtab, which unfortunately will block while in a frozen state.

RHEL 6 and newer kernels use relatime by default so the issue isn't as
prevalent (though an atime update can still occur if /etc/mtab hasn't been
updated since the last mtime update within the kernel's 24 hour limit.
Unlikely, since guest-fsfreeze-freeze causes an update, so you'd need to
wait that long before guest-fsfreeze-thaw would trigger it, since
/etc/mtab modifications would block within that time, but not still plausible)

If you can reproduce it on RHEL 6 using the "strictatime" mount option
for /etc's filesystem, and I think that should confirm it.

Previously to commit 9e8aded432884477bcd4fa1c7e849a196412bcc4, we stored
the mount list created by guest-fsfreeze-freeze, but that behavior was
changed so that qemu-ga could thaw the system regardless of whether
or not it was the same instance that did the freeze, so that's why
you're only seeing it in 1.1 RCs.

Your suggested fix seems reasonable, but I'm having a hard time figuring
out what the differences are between /etc/mtab and /proc/mounts, and
whether they can be safely ignored for our purposes. One issue seems to
be that it doesnt distinguish --bind mounts from real ones, but that at
least is handled gracefully with the newer code (qemu-ga might freeze
the filesystem multiple times, but the thaw implementation will thaw as
many times as it needs to to unfreeze).

If all seems well I'll send a patch this evening (or feel free to resend
your's with a signed-off-by for due credit)

> 
> Regards
> MATSUDA Daiki
> 
> --- qga/commands-posix.c.orig   2012-05-28 08:10:47.842332018 +0900
> +++ qga/commands-posix.c        2012-05-28 08:11:01.598340937 +0900
> @@ -347,7 +347,7 @@ static int guest_fsfreeze_build_mount_li
>  {
>      struct mntent *ment;
>      GuestFsfreezeMount *mount;
> -    char const *mtab = MOUNTED;
> +    char const *mtab = "/proc/mounts";
>      FILE *fp;
> 
>      fp = setmntent(mtab, "r");
> 
> > I encountered the serious bug on QEMU Guest Agent.
> > 
> > environment
> > Guest OS : RHEL 5.8 / 5.7 (i686)
> > Guest Agent Version : qemu-1.1.0rc2 and rc3
> > 
> > I am trying to take snapshot via virsh snapshot-create-as command. And
> > to freeze guest's filesystem and take snapshot is succeed. But after
> > sending the thaw command to Guest, time error occurs on libvirt qemu
> > agent because of not catch Guest's answer.
> > In addition, its situation is worst because the Guest Filesystem is kept
> > as frozen.
> > 
> > The problem does not occur on RHEL 6.2 Guest OS and in about qemu-1.0 it
> > does not occur.
> > 
> > Regards
> > MATSUDA Daiki
> > 
> > 
> > 
> > 
> 

      reply	other threads:[~2012-05-28  0:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-25  5:57 [Qemu-devel] [BUG] qemu-ga: failed to fsfreeze-thaw on RHEL 5.8 Guest MATSUDA, Daiki
2012-05-27 23:12 ` MATSUDA, Daiki
2012-05-28  0:49   ` Michael Roth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120528004928.GF5615@illuin \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=matsudadik@intellilink.co.jp \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).