On Thu, 2016-05-05 at 11:00 +0200, Peter Krempa wrote: > > > > But if we don't change 'virsh maxvcpus --type kvm' to report > > the computed limit, instead of just the KVM limit as it does > > now, the problem reported by Shivaprasad will still exist... > > I think that should be fixed by documenting that the old API and virsh > command report bad results and should not be used rather than trying to > add syntax sugar that will pull the data from a different place. I disagree. We can't extend virConnectGetMaxVcpus() in any sensible way because that would break the ABI, but we can do so for the maxvcpus command: --type is already the same as the domcapabilities command, we just have to add --emulatorbin, --arch and --machine and trivially change the implementation. People using 'virsh maxvcpus' without passing any of the new options will get better data automatically, in a completely backward-compatible fashion, and we will have one less place where different APIs return slightly different results for no apparent reason (I'm looking at you, topology information). While virsh commands generally map directly to the libvirt function of the same name, that's not necessarily a strict requirement IMHO - especially when we're asking application developers *not* to use that API anymore, and pointing them to a different solution. We should lead by example here. -- Andrea Bolognani Software Engineer - Virtualization Team -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list