On Thu, Apr 10, 2008 at 12:40:02AM +0100, John Levon wrote:
> On Wed, Apr 09, 2008 at 02:38:34PM -0500, Eunice Moon wrote:
>
> > >> static vshCmdDef commands[] = {
> > >> {"help", cmdHelp, opts_help, info_help},
> > >>+#ifndef WITH_LDOMS
> > >> {"attach-device", cmdAttachDevice, opts_attach_device,
> > >> info_attach_device},
> > >You shouldn't need to comment out unsupported commands. They will
> > >return an error if they aren't supported. In fact, QEMU, KVM and
> > >OpenVZ only support a subset of the available operations.
> > >
> > OK. I will remove all these #ifdef WITH_LDOMS here.
>
> I'd personally strongly prefer:
>
> > >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.
Yes ... One thing to remember when implementing this is that you can't
just check if the driver struct has a NULL pointer (ie. does the
domain support suspend? conn->driver->domainSuspend != NULL).
The reason is that this assumption doesn't work in the remote case
which "implements" all driver calls and allows them to fail at the
server end. (Another corner case would be a driver which only
partially implements a call, so it has a driver entry in the struct
but it mostly returns VIR_ERR_NO_SUPPORT -- one example of this is
virDomainAttachDevice in the QEMU driver).
This is why, for migration, I added the '__virDrvSupportsFeature' call
which allows you to test for specific features of a driver, eg. Does
the driver support migration? Does the driver support the scheduler
calls? Is the driver remote?
An implementation would need to extend this call, make it available to
user code, and come up with a suitable set of features (where
feature != call).
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list