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@xxxxxxxxxxxxx
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/
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list