On Wed, Feb 11, 2015 at 04:31:53PM +0100, Michal Privoznik wrote:
> Dear list,
>
> I've ran into the following bug [1]. The problem is, even though we
> check whether memory-backend-{ram,file} devices are supported, qemu
> fails to start. As I see it, on one hand, qemu lies about supported
> devices (when I imitated libvirt capabilities check by hand on the
> command line). But on the other hand, libvirt is using '-M none' so even
> if qemu is fixed, the domain would be unable to start anyway.
>
> So I believe my question is, does anybody have a bright idea how to fix
> this? I don't think we want to extend our capabilities from a list to a
> matrix (where a machine type would select a list). Moreover, querying
> and creating the matrix would take ages. But then again, machine type is
> important. Maybe not so for -x86_64 but for -arm definitely! Or?
Historically we've tried to treat the machine type as a black box
or a simple "tag" which just affects some set of default settings
that guest sees.
That assumption has already broken down a little bit on x86 where
we need to distinguish PIIX vs Q35 in order todo correct PCI device
address assignment, take account of different default PCI host
bridge and PATA/SATA controller layout
We'll get more of that as we take non-x86 arches more seriously as
their machine types show even more variance in the defautl base
board layout/setup.
While we might try to get QEMU to provide introspection for the
machine types to query the default bus topology, I'm not convinced
that it will be a tractable problem to solve with an entirely metadata
driven approach. IOW I wouldn't be surprised if we end up with more
machine type specific code branches in libvirt for arm, etc.
> 1: https://bugzilla.redhat.com/show_bug.cgi?id=1191567
There are two reasons why we query & check the supported capabilities
from QEMU
1. There are multiple possible CLI args for the same feature and
we need to choose the "best" one to use
2. The feature is not supported and we want to give the caller a
better error message than they'd get from QEMU
I'm unclear from the bug which scenario applies here.
If it is scenario 2 though, I'd just mark it as CANTFIX or WONTFIX,
as no matter what we do the user would get an error. It is not worth
making our capability matrix a factor of 10+ bigger just to get a
better error message.
If it is scenario 1, I think the burden is on QEMU to solve. The
memory-backend-{file,ram} CLI flags shouldn't be tied to guest
machine types, as they are backend config setup options that should
not impact guest ABI.
Regards,
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list