[Libvir] [PATCH][RFC] libvirt ldoms support

John Levon levon at movementarian.org
Thu Apr 10 13:08:23 UTC 2008

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.


More information about the libvir-list mailing list