All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Brian Jackson <iggy@theiggy.com>, Xiongzi Ge <gexxx132@umn.edu>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Live Migration with different block devices
Date: Tue, 24 Jun 2014 17:16:12 -0600	[thread overview]
Message-ID: <53AA06BC.5090604@redhat.com> (raw)
In-Reply-To: <53A9EDAC.6040808@theiggy.com>

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On 06/24/2014 03:29 PM, Brian Jackson wrote:
> 
> 
> On 6/24/2014 2:22 PM, Xiongzi Ge wrote:
>> Hi,
>>
>>
>> When I do live migration, in the source and destination host, there are
>> different block devices, but qemu can not detect this. I used virtio
>> as the
>> driver in kvm and in the vdi device in the guest is /dev/vda.  So, 
>> the vm
>> guest can read different data from the same /dev/vda device.  I am
>> studying
>> this code to let qemu understand that, this is a new device.
>>
>> Does qemu recognize different block devices after live migration?
> 
> You aren't supposed to have different command line options when live
> migrating (with the exception of -incoming if you migrate that way). So
> whatever you are trying to do is unsupported.

Caveat - it IS supported to change command line options for things that
do NOT impact guest ABI.  For example, if you have /path/to/file as the
host location containing the guest image on the source, but
/other/path/file as the location on the destination, you CAN rewrite
that parameter (and in fact, libvirt DOES supporting the rewrite such
parameters if you use the 'virsh migrate --xml' option - after first
proving that your changes do not affect guest ABI).  But the onus is on
you to ensure that src:/path/to/file and dst:/other/path/file have the
SAME guest-visible contents at the time of the migration (this generally
requires that the two names be mappings to the same underlying network
resource; you can get trickier, but it starts to be at your peril,
because the guest is hosed if the two files differ in guest contents).

-- 
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 --]

  reply	other threads:[~2014-06-24 23:16 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 [this message]
2014-06-25  0:08     ` Xiongzi Ge
2014-06-25  2:10       ` Eric Blake
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=53AA06BC.5090604@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.