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>
Older versions of libxml2 could not correctly parse certain
URIs. This causes test failures. There's nothing libvirt can
do about this, so disable the problem tests on old libxml2
versions
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The PyDict_Next method on Python <= 2.4 used 'int' instead
of "Py_ssize_t" for the 'pos' parameter
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
Currently, using an invalid XML in tests fails, because
the schema test expects all of them to be valid.
Treat files with -invalid.xml suffix as invalid and expect
them to fail validation.
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>
