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