From: Wei Liu <wei.liu2@citrix.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xen.org
Subject: Re: live migrating hvm from 4.4 to 4.5 fails due to kvmvapic
Date: Fri, 13 May 2016 10:43:00 +0100 [thread overview]
Message-ID: <20160513094300.GP27070@citrix.com> (raw)
In-Reply-To: <20160512154813.GB2960@aepfle.de>
On Thu, May 12, 2016 at 05:48:13PM +0200, Olaf Hering wrote:
> Migrating a HVM guest from staging-4.4 to staging-4.5 fails:
>
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> char device redirected to /dev/pts/4 (label serial0)
> xen_ram_alloc: do not alloc f800000 bytes of ram at 0 when runstate is INMIGRATE
> xen_ram_alloc: do not alloc 800000 bytes of ram at f800000 when runstate is INMIGRATE
> xen_ram_alloc: do not alloc 10000 bytes of ram at 10000000 when runstate is INMIGRATE
> xen_ram_alloc: do not alloc 40000 bytes of ram at 10010000 when runstate is INMIGRATE
> Unknown savevm section or instance 'kvm-tpr-opt' 0
> qemu-system-i386: load of migration failed: Invalid argument
>
>
> Initially I thought we broke our sles12 xen, but for some reason xen.git fails
> in the very same way. In 4.4 kvmvapic gets enabled, it gets migrated in the
> "kvm-tpr-opt" VMStateDescription. The 4.5 qemu does not know about it because
> 'kvmvapic' is not enabled. As a result the entire savevm stream is rejected.
>
> One thing to fix it in staging-4.5 is to introduce a dummy device which
> handles a section named "kvm-tpr-opt". I already have a hack which does
> that, and the migration proceeds. I will propose a patch to deal with
> this part of the bug.
>
> Unfortunately later the VM appears to be alive, but nothing happens in
> it. I assume it gets no further interrupts. Guess I need help with this
> part of the bug.
>
>
My fear is that the VM might actually be poking at that device. That
explains why the migration is successful but the VM is not functioning.
I think the first thing would be to confirm whether the guest is
actually using that device.
For newly created guest on xen 4.4, you will need some rune in guest cfg
file to explicitly disable that device. There is device_model_args=
option for you to do that.
For guests that are already running, you can try to massage the guest
cfg before sending, post receiving but before creating, or hack libxl to
add that kvm device.
But all things said above are just workaround. Unfortunately I don't see
an easy way of solving this off the top of my head.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-05-13 9:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-12 15:48 live migrating hvm from 4.4 to 4.5 fails due to kvmvapic Olaf Hering
2016-05-12 21:45 ` Olaf Hering
2016-05-13 9:41 ` Stefano Stabellini
2016-08-02 14:41 ` Olaf Hering
2016-08-02 18:53 ` Stefano Stabellini
2016-05-13 9:43 ` Wei Liu [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=20160513094300.GP27070@citrix.com \
--to=wei.liu2@citrix.com \
--cc=olaf@aepfle.de \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xen.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).