Re: [RFC] Per machine type qemu capability detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 04, 2013 at 06:30:08PM +0200, Peter Krempa wrote:
> On 04/04/13 18:22, Daniel P. Berrange wrote:
> >On Thu, Apr 04, 2013 at 06:20:05PM +0200, Peter Krempa wrote:
> >>Hi,
> >>
> >>qemu recently added a qmp/hmp command ("get-cpu-max") to determine
> >>maximum number of supported CPUs for a VM. The output of this
> >>command depends on the machine type that is used when it is called.
> >>The problem here is that libvirt uses "-M none" while detecting
> >>capabilities and with that machine type the get-cpu-max command
> >>returns always 1.
> >>
> >>My question is: Is it worthwhile to do per machine type capability
> >>detection? It definitely isn't worth doing just for the get-cpu-max
> >>support, but it might be needed for Q35 or other stuff that may
> >>depend on the actual machine type used.
> >>
> >>Pros of this approach:
> >>----------------------
> >>- (possibly) more accurate capabilities
> >>
> >>
> >>Cons:
> >>-----
> >>- ~10x more qemus started on libvirtd startup (one per machine type)
> >
> >That "con" simply rules it out entirely, not matter what "pro"
> >points there may be I'm afraid.
> 
> Yes, that's why I'm asking if there isn't a better use case that
> could justify the overhead.
> >
> >For your example here though, why do we need a capabiltiy for that?
> >Can't we just call get-cpu-max from the specific libvirt API calls
> >that actually want that info.
> 
> I planed to use it to validate configuration when parsing domain
> XMLs where it would come handy to have the data pre-cached. Also I
> don't think it's wise to invoke a qemu when a domain XML is being
> parsed to find out if the configuration is valid.

I think it is preferrable to *not* do such validation at
parse / load time, but rather only when starting the guest
or invoking some API on a running guest.

You have todo the validation when starting the guest anyway,
since you can't assume you still have the same QEMU installed
as was available when virDomainDefine was invoked.

Doing validation at parse time based on QEMU capabilities
already causes some pain. For example, if you temporarily
uninstall QEMU, then libvirt will fail to load any XML
files since it can't validate the machine types from the
QEMU capabilities. This rather sucks - it should really
only fail if you actually tried to start the VM, not merely
loading the config. So I think it is better not to add
more of this time of validation at parse time, and even
possibly remove what we already have.

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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]