From: Amit Shah <amit.shah@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix?
Date: Tue, 22 Jul 2014 12:41:30 +0530 [thread overview]
Message-ID: <20140722071130.GF26186@grmbl.mre> (raw)
In-Reply-To: <FD820C40-CB60-48E3-B6C6-BE6B51D8AE87@alex.org.uk>
On (Sat) 19 Jul 2014 [12:37:31], Alex Bligh wrote:
> Paolo,
>
> On 19 Jul 2014, at 11:53, Paolo Bonzini <pbonzini@redhat.com> wrote:
<snip>
> >> However, after the block migration is finished, I now see:
> >>
> >> Receiving block device images
> >> Completed 100 %
> >> Unknown savevm section type 255
> >> load of migration failed
> >
> > This could be another incompatibility between qemu-kvm and qemu. I know
> > we had a couple in Fedora.
> >
> >> My guess is this might be the bogus inclusion of PITCommonState
> >> per the last hunk of
> >> http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qemu-kvm.patch?h=f20
> >>
> >> Is there a technique to debug this sort of thing?
> >
> > You can try using Amit's vmstate checker.
>
> I think this requires a json output in the format given by -dump-vmstate
> (unless we're at cross purposes). qemu 1.0 does not produce such a JSON
> output. I only have the vmstate to go on (same problem exists if
> -S is used throughout so the VM never starts and without block migration).
My long-term plan is to put all the json dumps in the git tree, so
comparing these jsons at release-time becomes easy.
I've backported the -dump-vmstate patches to qemu-1.0, the backport is
here:
http://paste.fedoraproject.org/119724/14060126/
(I'll be publishing these to my git repo soon.)
and the json dump is here:
http://paste.fedoraproject.org/119725/01268914/
Comparing qemu-1.0 to qemu-2.1 -M pc-1.0 gives a few errors:
$ ./scripts/vmstate-static-checker.py -s v1.0-1.0.json -d upstream-20140722-v1.0.json
Section "xio3130-downstream" Description "xio3130-express-downstream-port": version error: 2 > 0
Section "xio3130-downstream": Description "PCIDevice" missing, got "PCIEDevice" instead; skipping
Section "usb-ccid", Description "usb-ccid": expected field "abProtocolDataStructure", got "abProtocolDataStructure.data"; skipping rest
Section "ich9-ahci": Description "ahci" missing, got "ich9_ahci" instead; skipping
Section "usb-host" Section "usb-host" Description "usb-host": minimum version error: 0 < 1
Section "ich9-usb-ehci1" Section "ich9-usb-ehci1" Description "ehci": minimum version error: 0 < 1
Section "x3130-upstream" Description "xio3130-express-upstream-port": version error: 2 > 0
Section "x3130-upstream": Description "PCIDevice" missing, got "PCIEDevice" instead; skipping
Section "vmware-svga", Description "vmware_vga": expected field "card", got "parent_obj"; skipping rest
Section "usb-ehci" Section "usb-ehci" Description "ehci": minimum version error: 0 < 1
Section "apic", Description "apic": expected field "timer", got "timer_expiry"; skipping rest
Section "ioh3420" Description "ioh-3240-express-root-port": version error: 2 > 0
Section "ioh3420": Description "PCIDevice" missing, got "PCIEDevice" instead; skipping
Section "isa-pit", Description "i8254": expected field "channels", got "channels[0].irq_disabled"; skipping rest
Section "PIIX4_PM" Section "PIIX4_PM" Description "piix4_pm": minimum version error: 2 < 3
Section "PIIX4_PM", Description "piix4_pm": expected field "pm1a.sts", got "ar.pm1.evt.sts"; skipping rest
Section "lsi53c895a", Description "lsiscsi": expected field "dev", got "parent_obj"; skipping rest
Section "mc146818rtc", Description "mc146818rtc": expected field "current_tm.tm_sec", got "unused"; skipping rest
Of these, section renames can be handled by whitelisting them in the
script. The version and minimum_version errors will have to be looked
at in detail.
Hopefully you can use these results and share your findings.
Amit
next prev parent reply other threads:[~2014-07-22 7:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-18 23:33 [Qemu-devel] Live migrate, inconsistent machine types - new machine type to fix? Alex Bligh
2014-07-19 5:51 ` Paolo Bonzini
2014-07-19 7:10 ` Alex Bligh
2014-07-19 7:30 ` Paolo Bonzini
2014-07-19 8:43 ` Alex Bligh
2014-07-19 8:54 ` Peter Maydell
2014-07-19 8:59 ` Alex Bligh
2014-07-19 10:53 ` Paolo Bonzini
2014-07-19 11:37 ` Alex Bligh
2014-07-21 10:22 ` Paolo Bonzini
2014-07-21 13:59 ` Alex Bligh
2014-07-21 14:11 ` Paolo Bonzini
2014-07-21 14:35 ` Alex Bligh
2014-07-21 14:14 ` Paolo Bonzini
2014-07-22 7:11 ` Amit Shah [this message]
2014-07-22 9:50 ` Amit Shah
2014-07-22 9:55 ` Paolo Bonzini
2014-07-22 10:22 ` Amit Shah
2014-07-22 10:32 ` Alex Bligh
2014-07-22 10:54 ` Amit Shah
2014-07-22 11:38 ` Alex Bligh
2014-07-22 11:54 ` Amit Shah
2014-07-22 12:12 ` Paolo Bonzini
2014-07-22 12:19 ` Alex Bligh
2014-07-22 12:47 ` Amit Shah
2014-07-22 12:40 ` Amit Shah
2014-07-22 12:15 ` Alex Bligh
2014-07-22 12:44 ` Amit Shah
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=20140722071130.GF26186@grmbl.mre \
--to=amit.shah@redhat.com \
--cc=alex@alex.org.uk \
--cc=pbonzini@redhat.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 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).