From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [libvirt] [PATCH RFC 0/4] Allow hibernation on guests
Date: Thu, 26 Jan 2012 18:01:13 -0600 [thread overview]
Message-ID: <4F21E949.6050103@linux.vnet.ibm.com> (raw)
In-Reply-To: <4F216EAB.2000707@redhat.com>
On 01/26/2012 09:18 AM, Eric Blake wrote:
> [adding qemu-devel]
>
> On 01/26/2012 07:46 AM, Daniel P. Berrange wrote:
>>> One thing, that you'll probably notice is this
>>> 'set-support-level' command. Basically, it tells GA what qemu version
>>> is it running on. Ideally, this should be done as soon as
>>> GA starts up. However, that cannot be determined from outside
>>> world as GA doesn't emit any events yet.
>>> Ideally^2 this command should be left out as it should be qemu
>>> who tells its own agent this kind of information.
>>> Anyway, I was going to call this command in qemuProcess{Startup,
>>> Reconnect,Attach}, but it won't work. We need to un-pause guest CPUs
>>> so guest can boot and start GA, but that implies returning from qemuProcess*.
>>>
>>> So I am setting this just before 'guest-suspend' command, as
>>> there is one more thing about GA. It is unable to remember anything
>>> upon its restart (GA process). Which has BTW show flaw
>>> in our current code with FS freeze& thaw. If we freeze guest
>>> FS, and somebody restart GA, the simple FS Thaw will not succeed as
>>> GA thinks FS are not frozen. But that's a different cup of tea.
We could drop the state tracking (guest-fsfreeze-status) and issue the
freeze/thaw unconditionally. Talked with Anthony and going stateless in
general seems to solve a lot of nastiness that might pop up with the
current implementation. I'll send some patches out soon for fsfreeze,
guest-file* may end up getting similar treatment in the
not-too-distant-future.
prev parent reply other threads:[~2012-01-27 0:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1327585806.git.mprivozn@redhat.com>
[not found] ` <20120126144632.GM21211@redhat.com>
2012-01-26 15:18 ` [Qemu-devel] [libvirt] [PATCH RFC 0/4] Allow hibernation on guests Eric Blake
2012-01-26 19:35 ` Luiz Capitulino
2012-01-26 19:41 ` Michal Privoznik
2012-01-26 20:13 ` Luiz Capitulino
2012-01-26 22:51 ` Michael Roth
2012-01-26 22:57 ` Anthony Liguori
2012-01-30 12:57 ` Luiz Capitulino
2012-01-30 13:54 ` Anthony Liguori
2012-01-30 14:44 ` Luiz Capitulino
2012-01-30 15:43 ` Michael Roth
2012-01-30 15:58 ` Eric Blake
2012-01-30 17:07 ` Michael Roth
2012-01-30 18:30 ` Luiz Capitulino
2012-01-30 16:08 ` Michal Privoznik
2012-01-30 18:36 ` Luiz Capitulino
2012-01-30 15:03 ` Michael Roth
2012-01-26 22:54 ` Anthony Liguori
2012-01-27 0:01 ` 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=4F21E949.6050103@linux.vnet.ibm.com \
--to=mdroth@linux.vnet.ibm.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mprivozn@redhat.com \
--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).