[libvirt] Upgrade-problems from qemu-0.14.1 + libvirt-0.8.4 to qemu-0.15.1 + libvirt-0.9.6: Why I think multifunction=on is a bad idea...
3:19 p.m.
Hello,
this mail is something between a bug report and a warning to other users of
libvirt, before they also experience the problem I encountered today:
I just hat the painful experience of trying to install some newer versions of
qemu(-kvm) and libvirt on a system with many managedsave-states and many
snapshots. They are now all broken because
1. Newer qemu(-kvm) uses iPXE instead of etherboot, which have different ROM
file sizes, which aborts loading the old VM state. So be careful to not
delete your old PXE-ROM images.
2. libvirt defaults to add ',multifuntion=on' to the (in my case) rtl8139
network card and balloon-driver, which produces the "really helpful" message
of
qemu: warning: error while loading state for instance 0x0 of
device '0000:00:03.0/rtl8139'
or
qemu: warning: error while loading state for instance 0x0 of device 'ram'
Nothing you can't fix with installing the old etherboot-qemu package and some
dirty "dd"-hackery on your saved files and snapshot xml files to add an
explicit 'multifunction=off', but hard to diagnose and annoying enough.
So even if the qemu people try to be backward compatible with their VMState
format, libvirt doesn't seem to handle backward compatibility taht good at
the moment.
Perhaps it would help to not (only) store the XML domain configuration for
snapshots and managedsave-files, but the exact qemu-argv string to at least
get libvirt out of any backward incompatible changes when re-constructing the
qemu command line from the XML data.
Sincerely
Philipp
PS: I hope that info helps other people when getting those messages.
--
Philipp Hahn Open Source Software Engineer hahn(a)univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
3:33 p.m.
On 11/15/2011 02:19 PM, Philipp Hahn wrote:
Hello,
this mail is something between a bug report and a warning to other users of
libvirt, before they also experience the problem I encountered today:
I just hat the painful experience of trying to install some newer versions of
qemu(-kvm) and libvirt on a system with many managedsave-states and many
snapshots. They are now all broken because
1. Newer qemu(-kvm) uses iPXE instead of etherboot, which have different ROM
file sizes, which aborts loading the old VM state. So be careful to not
delete your old PXE-ROM images.
Is there a way to select which ROM image qemu uses from the qemu command
line? And should libvirt be exposing this in the domain XML? I agree
that it is a bad idea to make any backwards-incompatible ABI changes,
and if changing out the PXE-ROM image renders a save file broken, then
it argues that libvirt should be exposing this detail in the XML and
allow for a backwards-compatible default.
2. libvirt defaults to add ',multifuntion=on' to the (in my
case) rtl8139
network card and balloon-driver,
I thought that was a bug in 0.9.5, but fixed in the 0.9.6 release just
several days later. That is, we already agreed that 0.9.5 exposed the
problem of blindly enabling multifunction as being an ABI breaker, and
that 0.9.6 fixed things so that you have to explicitly request
multifunction in the XML. But now you're saying 0.9.6 was also faulty?
How about 0.9.7? Do you have a better formula for reproducing this?
So even if the qemu people try to be backward compatible with their
VMState
format, libvirt doesn't seem to handle backward compatibility taht good at
the moment.
Perhaps it would help to not (only) store the XML domain configuration for
snapshots and managedsave-files, but the exact qemu-argv string to at least
get libvirt out of any backward incompatible changes when re-constructing the
qemu command line from the XML data.
That won't help. The XML data should be properly translatable in an
ABI-compatible manner, regardless if qemu is upgraded in the meantime;
worse, you have to remember that qemu command lines change across
releases, so guaranteeing ABI stability may require using _different_
command lines in 0.15 than it did in 0.14; saving the argv you handed to
qemu 0.14 won't help you; but saving a complete XML description that can
map to either qemu 0.14 or qemu 0.15 will. So if it is problem of an
incomplete XML mapping, then we'd like to fix it, and sooner rather than
later.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
5:54 a.m.
Hello Eric,
Am Dienstag 15 November 2011 22:33:20 schrieb Eric Blake:
Is there a way to select which ROM image qemu uses from the qemu
command
line?
The file names are explicitly added to the qemu command-line:
<qemu:commandline>
<qemu:arg value='-option-rom'/>
<qemu:arg value='/usr/share/kvm/pxe-virtio.bin'/>
</qemu:commandline>
> 2. libvirt defaults to add ',multifuntion=on' to the (in
my case) rtl8139
> network card and balloon-driver,
I thought that was a bug in 0.9.5, but fixed in the 0.9.6 release just
several days later. That is, we already agreed that 0.9.5 exposed the
problem of blindly enabling multifunction as being an ABI breaker, and
that 0.9.6 fixed things so that you have to explicitly request
multifunction in the XML. But now you're saying 0.9.6 was also faulty?
How about 0.9.7? Do you have a better formula for reproducing this?
It seems to be fixed with 0.9.7:
0.9.6 adds multifunction=on
0.9.7 adds multifunction=off
But qemu still refuses to load the image with
qemu: warning: error while loading state for instance 0x0 of device 'ram'
Back to using gdb to find out which specific blob fails...
That won't help. The XML data should be properly translatable in
an
ABI-compatible manner, regardless if qemu is upgraded in the meantime;
worse, you have to remember that qemu command lines change across
releases, so guaranteeing ABI stability may require using _different_
command lines in 0.15 than it did in 0.14; saving the argv you handed to
qemu 0.14 won't help you; but saving a complete XML description that can
map to either qemu 0.14 or qemu 0.15 will. So if it is problem of an
incomplete XML mapping, then we'd like to fix it, and sooner rather than
later.
Right you are, thank you for your feedback.
Sincerely
Philipp
--
Philipp Hahn Open Source Software Engineer hahn(a)univention.de
Univention GmbH Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99
http://www.univention.de/
7:50 a.m.
On 11/17/2011 04:54 AM, Philipp Hahn wrote:
Hello Eric,
Am Dienstag 15 November 2011 22:33:20 schrieb Eric Blake:
> Is there a way to select which ROM image qemu uses from the qemu command
> line?
The file names are explicitly added to the qemu command-line:
<qemu:commandline>
<qemu:arg value='-option-rom'/>
<qemu:arg value='/usr/share/kvm/pxe-virtio.bin'/>
</qemu:commandline>
So we definitely need to expose this in the XML; we already have
os/bios, so perhaps this would be the best location:
<domain ...>
<os>
<bios useserial='yes'>
<rom>/usr/share/kvm/pxe-virtio.bin</rom>
</bios>
</os>
...
and if /bios/rom[0] is not present, then we have to figure out how to
provide a sane default. Does qemu provide a -help option that says what
option-rom it will use if -option-rom was not provided on the command line?
Are you interested in working on patches on this front?
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
8:04 a.m.
On Thu, Nov 17, 2011 at 06:50:57AM -0700, Eric Blake wrote:
On 11/17/2011 04:54 AM, Philipp Hahn wrote:
> Hello Eric,
>
> Am Dienstag 15 November 2011 22:33:20 schrieb Eric Blake:
>> Is there a way to select which ROM image qemu uses from the qemu command
>> line?
>
> The file names are explicitly added to the qemu command-line:
> <qemu:commandline>
> <qemu:arg value='-option-rom'/>
> <qemu:arg value='/usr/share/kvm/pxe-virtio.bin'/>
> </qemu:commandline>
So we definitely need to expose this in the XML; we already have
os/bios, so perhaps this would be the best location:
<domain ...>
<os>
<bios useserial='yes'>
<rom>/usr/share/kvm/pxe-virtio.bin</rom>
</bios>
</os>
...
I wouldn't bother with that nesting - just put it directly inside <os>.
Several other things in there are all associated with the bios.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4755
days inactive
4757
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Philipp Hahn