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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list