From: "Daniel P. Berrange" <berrange@redhat.com>
To: Bob Chen <a175818323@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Live migration + cpu/mem hotplug
Date: Thu, 5 Jan 2017 10:12:46 +0000 [thread overview]
Message-ID: <20170105101246.GC3292@redhat.com> (raw)
In-Reply-To: <CAMxP3BTmayVS5VHYm6iXgZFetiv8YAPnyd_1-6p_q33gDLTrEQ@mail.gmail.com>
On Thu, Jan 05, 2017 at 04:27:26PM +0800, Bob Chen wrote:
> Hi,
>
> According to the docs, the destination Qemu must have the exactly same
> parameters as the source one. So if the source has just finished cpu or
> memory hotplug, what would the dest's parameters be like?
>
> Does DIMM device, or logically QOM object, have to be reflected on the new
> command-line parameters?
Yes, if you have hotplugged any type of device since the VM was started,
the QEMU command line args on the target host must include all the original
args from the source QEMU, and also any args reflect to reflect the
hotplugged devices too.
A further complication is that on the target, you must also make sure you
fully specify *all* device address information (PCI slots, SCSI luns, etc
etc), because the addresses QEMU assigns to a device after hotplug may
not be the same as the addresses QEMU assigns to a device whne coldplug.
eg if you boot a guest with 1 NIC + 1 disk, and then hotplug a 2nd NIC
you might get
1st NIC == PCI slot 2
1st disk == PCI slot 3
2nd NIC == PCI slot 4
if however, you started QEMU with 2 NICs and 1 disk straight away QEMU
might assign addresses in the order
1st NIC == PCI slot 2
2nd NIC == PCI slot 3
1st disk == PCI slot 4
this would totally kill a guest OS during live migration as the slots
for devices its using would change.
So as a general rule when launching QEMU on a target host for migrating,
you must be explicit about all device addresses and not rely on QEMU to
auto-assign addresses. This is quite alot of work to get right, but if
you're using libvirt it'll do pretty much all this automatically for
you.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-01-05 10:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 8:27 [Qemu-devel] Live migration + cpu/mem hotplug Bob Chen
2017-01-05 10:12 ` Daniel P. Berrange [this message]
2017-01-10 6:28 ` Bob Chen
2017-01-10 9:10 ` Igor Mammedov
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=20170105101246.GC3292@redhat.com \
--to=berrange@redhat.com \
--cc=a175818323@gmail.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.