On Thu, Apr 10, 2008 at 05:11:28AM +0100, Daniel P. Berrange wrote:
However if you want to propose a more general patch which allows virsh to determine which operations are supported on the current connection, then I'm all for it. Some of the infrastructure is in place to do this already.
It's particularly unfriendly to the user to have a whole bunch of apparent commands that actually don't work.
Then consider though that the underlying HV impl you talk to may or may not implement the API. ie, PCI hotplug only got added to Xen in Xen version 3.2.0. So now you can't simply probe the indiivdual libvirt driver, you need to figure out whether the underlying HV supports that - and often it won't tell you / provide a way to find out - you just have to try the call and watch it fail
This is fair point, but there's a big difference between "we know this is definitely not going to work" and "this one's tricky". That is, an imperfect implementation still has significant UI benefits.
Then further consider that different types of VM support different ops, eg Xen PV supports disk notplug, but Xen HVm does not. Except when you have installed PV drivers inside the guest, but libvirt has no idea whether the guest admin has installed PV drivers or not.
This particular case is easily fixable using the same method xend does.
So I don't think it is practical to figure out whether each individual command from virsh works without actually trying them, so you can't hide them from the user. Removing commands at compile time with #ifdef is basically guarenteed wrong in.
I agree with that. We need runtime basic probing at least. From that point, we can improve things as needed. regards john