The previous update of method naming missed the ESX storage
backend files. Update them is that the driver impl methods
follow the naming of the public API but with s/vir/esx/
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virNWFilterTechDriver struct is an internal only driver
API with no public API equivalent. It should be skipped by
the 'check-driverimpls' test case
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Some methods in the udev interface driver used 'cleanup' as the
label for separate error codepaths. Change these to use 'error'
as required by coding standards
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Print an error instead of crashing when a TPM device without
a backend is specified.
Add a test for tpm device with no backend, which should fail
with a parse error.
https://bugzilla.redhat.com/show_bug.cgi?id=961252
Make the Xen domain stats / peek and node memory driver
methods unconditionally call the sub-drivers which are
guaranteed to be open.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the Xen domain scheduler parameter methods directly
call into XenD or Xen hypervisor drivers
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the domain define/undefine driver methods directly call
into either the XenD or XM drivers
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The xenUnifiedDomainGetXMLDesc driver can assume that
the XM and XenD drivers are always present
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the xenUnifiedDomainGetInfo and xenUnifiedDomainGetState drivers
call the correct sub-driver APIs directly.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make xenUnifiedDomainGetOSType directly call either the
xenHypervisorDomainGetOSType or xenDaemonDomainGetOSType
method depending on whether the domain is active or not.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Unconditionally call the xenDaemonDomainDestroyFlags API
since the XenD driver is always available.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Make the xenUnifiedDomainShutdownFlags and xenUnifiedDomainReboot
driver methods unconditionally call the XenD APIs for shutdown
and reboot. Delete the unreachable impls in the XenStore driver.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Update xenUnifiedDomainSuspend and xenUnifiedDomainResume to
unconditionally invoke the XenD APIs for suspend/resume. Delete
the impls in the hypervisor driver which was unreachable.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Unconditionally invoke the xenHypervisorLookupDomainByID,
xenHypervisorLookupDomainByUUID or xenDaemonLookupByName
for looking up domains. Fallback to xenXMDomainLookupByUUID
and xenXMDomainLookupByName for legacy XenD without inactive
domain support
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Unconditionally call xenDaemonCreateXML in the
xenUnifiedDomainCreateXML driver, since the XenD
driver is always present.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The XenStore driver is mandatory, so it can be used unconditonally
for the xenUnifiedConnectListDomains & xenUnifiedConnectNumOfDomains
drivers. Delete the unused XenD and Hypervisor driver code for
listing / counting domains
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Unconditionally call into xenHypervisorGetMaxVcpus and
xenDaemonNodeGetInfo respectively, since those drivers
are both mandatory
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The hypervisor driver is mandatory, so the the call to
xenHypervisorGetVersion must always succeed. Thus there
is no need to ever run xenDaemonGetVersion
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
There is no point iterating over sub-drivers since the user
would not have a virConnectPtr instance at all if opening
the drivers failed. Just return 'Xen' immediately.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Since the Xen driver was changed to only execute inside libvirtd,
there is no scenario in which it will be opened from a non-privileged
context. Thus all the code dealing with opening the sub-drivers can
be simplified to assume that they are always privileged.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The Xen driver uses a macro GET_PRIVATE as a supposed shorthand
for 'xenUnifiedPrivatePtr priv = (xenUnifiedPrivatePtr) (conn)->privateData'.
It does not in fact save any lines of code, and obscures what is
happening. Remove it, since it adds no value.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Some of the Xen sub-drivers have checks against the
VIR_CONNECT_RO flag. This is not required, since such
checks are done at the top level before the driver
methods are invoked
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The Xen hypervisor driver checks for 'priv->handle < 0' and
returns -1, but without raising any error. Fortunately this
code will never be executed, since the main Xen driver always
checks 'priv->opened[XEN_UNIFIED_HYPERVISOR_OFFSET]' prior
to invoking any hypervisor API. Just remove the redundant
checks for priv->handle
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
