Re: [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...
Hello, On Thursday 17 November 2011 18:39:15 Eric Blake wrote: Is any of this worth keeping on the public libvir-list? Not much but to be careful when you upgrade any part of libvirt, qemu(-kvm) or it's (external*) dependencies like etherboot/iPXE, vgabios and seabios, because it can invalidate your snapshots and saved state. (*): As Debian does for DFSG-compliance, since it replaces the seabios / vgabios / pxe-bios as shipped with qemu by a version compiled from (different) sources. Sincerely Philipp -- Philipp Hahn Open Source Software Engineer h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ signature.asc Description: This is a digitally signed message part. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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...
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 h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ signature.asc Description: This is a digitally signed message part. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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...
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 ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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...
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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[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...
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 ':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 h...@univention.de Univention GmbHLinux for Your Businessfon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ signature.asc Description: This is a digitally signed message part. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [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...
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 ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
