From: Eric Blake <eblake@redhat.com>
To: Xiongzi Ge <gexxx132@umn.edu>
Cc: Brian Jackson <iggy@theiggy.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Live Migration with different block devices
Date: Tue, 24 Jun 2014 20:10:26 -0600 [thread overview]
Message-ID: <53AA2F92.2020103@redhat.com> (raw)
In-Reply-To: <CACtCCo9xqwaCZ+weHaaya5kVvT1EqqEO_C7WU3i7+pL5Ppp5Mg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1547 bytes --]
On 06/24/2014 06:08 PM, Xiongzi Ge wrote:
> Hi Eric,
[we tend to avoid top-posting on technical lists]
>
> This really works if I set up the same configuration (/dev/vda in the
> guest) but the physical block devices are not the same after migration.The
> ABI is the same. When the guest cache stores a page like 'aaa' which is in
> the block device of Host A. If the cache in the guest is also migrated to
> Host B, but data in the block device actually are "bbb" in Host B now.
The ABI is NOT the same if the two host files do not have identical
contents; it's just that qemu cannot diagnose your bug.
> What
> will happen? Will the cache data in the guest be migrated to the other
> host? The vmstate function in the qemu seems doing something to save the
> vm state and the device state.
>
Who knows what happen? You're in undefined territory, because you
violated the premise that migration does not change disk contents behind
the guest's back.
> Should the guest re-open the block device and delete the previous cache
> data or just check the consistency of the cache and the block device?
Rather than trying to figure out what happens with undefined behavior,
how about you hot-unplug the old host device, then migrate, then
hot-plug the new host device. That way, the guest will KNOW it it is
connecting to a second disk, and not be confused by anything it cached
about the first.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-06-25 2:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 19:22 [Qemu-devel] Live Migration with different block devices Xiongzi Ge
2014-06-24 21:29 ` Brian Jackson
2014-06-24 23:16 ` Eric Blake
2014-06-25 0:08 ` Xiongzi Ge
2014-06-25 2:10 ` Eric Blake [this message]
2014-06-25 6:18 ` Paolo Bonzini
2014-06-25 14:14 ` Xiongzi Ge
2014-06-25 14:18 ` Paolo Bonzini
2014-06-25 14:32 ` Xiongzi Ge
2014-06-25 14:39 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2014-06-24 19:18 Xiongzi Ge
2014-06-24 19:37 ` Paolo Bonzini
2014-06-24 19:55 ` Xiongzi Ge
2014-06-24 20:25 ` Paolo Bonzini
2014-06-24 20:34 ` Xiongzi Ge
2014-06-24 20:41 ` Eric Blake
2014-06-24 20:47 ` Paolo Bonzini
2014-06-24 21:26 ` Xiongzi Ge
2014-06-24 21:39 ` Christopher Covington
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=53AA2F92.2020103@redhat.com \
--to=eblake@redhat.com \
--cc=gexxx132@umn.edu \
--cc=iggy@theiggy.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.