From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Lucas Meneghel Rodrigues <lmr@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
KVM mailing list <kvm@vger.kernel.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"libvir-list@redhat.com" <libvir-list@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
QEMU devel <qemu-devel@nongnu.org>,
Juan Jose Quintela Carreira <quintela@redhat.com>
Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions
Date: Thu, 10 Nov 2011 15:30:08 -0600 [thread overview]
Message-ID: <4EBC4260.1090405@codemonkey.ws> (raw)
In-Reply-To: <4EBC1792.3030004@codemonkey.ws>
On 11/10/2011 12:27 PM, Anthony Liguori wrote:
> On 11/10/2011 02:55 AM, Avi Kivity wrote:
>> If we have to delay the release for a month to get it right, we should.
>> Not that I think we have to.
>>
>
> Adding libvirt to the discussion.
>
> What does libvirt actually do in the monitor prior to migration completing on
> the destination? The least invasive way of doing delayed open of block devices
> is probably to make -incoming create a monitor and run a main loop before the
> block devices (and full device model) is initialized. Since this isolates the
> changes strictly to migration, I'd feel okay doing this for 1.0 (although it
> might need to be in the stable branch).
This won't work. libvirt needs things to be initialized. Plus, once loadvm
gets to loading the device model, the device model (and BDSes) need to be fully
initialized.
I think I've convinced myself that without proper clustered shared storage,
cache=none is a hard requirement. That goes for iSCSI and NFS. I don't see a
way to do migration safely with NFS and there's no way to really solve the page
cache problem with iSCSI.
Even with the reopen, it's racing against the close on the source. If you look
at Daniel's description of what libvirt is doing and then compare that to Juan's
patches, there's a race condition regarding whether the source gets closed
before the reopen happens. cache=none seems to be the only way to solve this.
Live migration with qcow2 or any other image format is just not going to work
right now even with proper clustered storage. I think doing a block level flush
cache interface and letting block devices decide how to do it is the best approach.
Regards,
Anthony Liguori
> I know a monitor can run like this as I've done it before but some of the
> commands will not behave as expected so it's pretty important to be comfortable
> with what commands are actually being used in this mode.
>
> Regards,
>
> Anthony Liguori
next prev parent reply other threads:[~2011-11-10 21:30 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-09 16:29 [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Lucas Meneghel Rodrigues
2011-11-09 16:39 ` Anthony Liguori
2011-11-09 17:02 ` Avi Kivity
2011-11-09 17:35 ` Anthony Liguori
2011-11-09 19:53 ` Juan Quintela
2011-11-09 20:18 ` Michael S. Tsirkin
2011-11-09 20:22 ` Anthony Liguori
2011-11-09 21:00 ` Michael S. Tsirkin
2011-11-09 21:01 ` Anthony Liguori
2011-11-10 10:41 ` Kevin Wolf
2011-11-10 16:50 ` Juan Quintela
2011-11-10 17:59 ` Anthony Liguori
2011-11-10 18:00 ` Anthony Liguori
2011-11-09 20:57 ` Juan Quintela
2011-11-10 8:55 ` Avi Kivity
2011-11-10 17:50 ` Juan Quintela
2011-11-10 17:54 ` Anthony Liguori
2011-11-12 10:20 ` Avi Kivity
2011-11-12 13:30 ` Anthony Liguori
2011-11-12 14:36 ` Avi Kivity
2011-11-10 18:27 ` Anthony Liguori
2011-11-10 18:42 ` Daniel P. Berrange
2011-11-10 19:11 ` Anthony Liguori
2011-11-10 20:06 ` Daniel P. Berrange
2011-11-10 20:07 ` Anthony Liguori
2011-11-10 21:30 ` Anthony Liguori [this message]
2011-11-11 10:15 ` Kevin Wolf
2011-11-11 14:03 ` Anthony Liguori
2011-11-11 14:29 ` Kevin Wolf
2011-11-11 14:35 ` Anthony Liguori
2011-11-11 14:44 ` Kevin Wolf
2011-11-11 20:38 ` Anthony Liguori
2011-11-12 10:27 ` Avi Kivity
2011-11-12 13:39 ` Anthony Liguori
2011-11-12 14:43 ` Avi Kivity
2011-11-12 16:01 ` Anthony Liguori
2011-11-12 10:25 ` Avi Kivity
2011-11-14 9:58 ` Kevin Wolf
2011-11-14 10:10 ` Michael S. Tsirkin
2011-11-15 13:28 ` Avi Kivity
2011-11-14 10:16 ` Daniel P. Berrange
2011-11-14 10:24 ` Michael S. Tsirkin
2011-11-14 11:08 ` Daniel P. Berrange
2011-11-14 11:21 ` Kevin Wolf
2011-11-14 11:29 ` Daniel P. Berrange
2011-11-14 11:34 ` Michael S. Tsirkin
2011-11-14 11:37 ` Daniel P. Berrange
2011-11-14 11:51 ` Michael S. Tsirkin
2011-11-14 11:55 ` Daniel P. Berrange
2011-11-14 11:56 ` Michael S. Tsirkin
2011-11-14 11:58 ` Daniel P. Berrange
2011-11-14 12:17 ` Michael S. Tsirkin
2011-11-14 11:36 ` Gleb Natapov
2011-11-14 11:32 ` Michael S. Tsirkin
2011-11-14 14:19 ` Anthony Liguori
2011-11-15 13:20 ` Juan Quintela
2011-11-15 13:56 ` Anthony Liguori
2011-11-09 19:25 ` Juan Quintela
2011-11-09 23:33 ` Lucas Meneghel Rodrigues
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=4EBC4260.1090405@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=libvir-list@redhat.com \
--cc=lmr@redhat.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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).