Rather than VIR_ALLOC, use the New function for allocation. We
already use the Free function anyway.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Rather than using VIR_ALLOC, use the New API since we already
use the virDomainChrSourceDefFree function when done.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The array of strings we are building is indeed array of const
strings. We are not STRDUP()-ing them nor FREE()-ing them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
We test the same XML for a type='kvm' domain twice, once with
QEMU_CAPS_KVM (expecting success), once without (expecting failure).
The failure case relies on QEMU_CAPS_MACHINE_OPT not being set,
failing in qemuBuildObsoleteAccelArg.
Checking a domain-type error message in a cpu test is strange.
Delete the negative test to allow assuming QEMU_CAPS_MACHINE_OPT by
default.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Use QEMU_CAPS_MACHINE_OPT and QEMU_CAPS_MACHINE_VMPORT_OPT
since it specifies <vmport state=off/>.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since virCloseCallbacksRun was ignoring the value anyway, let's
just change it to be a void function.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Upon entry from virCloseCallbacksRun, the @dom will have a
Ref and Lock from virDomainObjListFindByUUIDRef, so there's
no need to take an extra reference nor should the code call
virDomainObjEndAPI when done since that both Unref's and
Unlock's the @dom which means the callers call to EndAPI
would be unlocking an unlocked object. At least the Ref
saved the code from referencing something already freed.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Now that the old Xen driver is removed, update the drvxen
page with current information on the libxl drvier and remove
all the old cruft.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
xend was deprecated in Xen 4.2 and removed from the Xen sources
before the Xen 4.5 release. The last Xen release to contain xend
was Xen 4.4, which was retired upstream in March 2017.
Remove xend support from libvirt since it is unrealistic to use
modern libvirt with ancient Xen.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In preparation of removing the legacy Xen driver, move the
xmconfig tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert xm config to XML. Requires fixing up the tests to account
for different behavior of Xen vs libxl post parse functions. For
consistency with other Xen config tests, change the <os> arch to
x86_64.
There is some test file fallout due to differences in handling of
default values between xend and libxl.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In preparation of removing the legacy Xen driver, move the
sexpr2xml tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert sexpr to XML. Requires fixing up the tests to account
for different behavior of Xen vs libxl post parse functions.
There is some test file fallout due to differences in handling
of default values between xend and libxl.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In preparation of removing the legacy Xen driver, move the
xml2sexpr tests from WITH_XEN to WITH_LIBXL. Even though the
legacy driver will be removed, we'll want to maintain the ability
to convert sexpr <-> XML.
There is some test file fallout due to differences in handling
of default values between xend and libxl.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There will shortly be many connection objects, so we should not assume a
single check against priv->conn is sufficient.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Calling a push_privconn method to directly push the connection object
name into the arg list is inconvenient. Refactor so that we acquire
the connection variable name upfront, and push it to the arg list
separately. This allows various hardcoded usage of "priv->conn" to
be parameterized.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Described how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
I haven't been able to come up with a single scenario in which
the code in question would be executed; even if there was one,
it would be due to the user specifying a *partial* PCI topology
in the guest XML, which is of course entirely unsupportable and
thus providing even the slightest hint that doing so is in any
way a good idea is actively harmful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since the introduction of log tuning capabilities to virt-admin by
@06b91785, this has been a much needed missing improvement on the way to
deprecate the global 'log_level'.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When applying the log filters, one has to define the more specific
filters before the generic ones, because the first filter that matches
will be applied. However, we've been missing this information in the
config, so it always has been a trial-error scenario figuring out that
e.g. '4:util 1:util.pci' doesn't actually enable verbose logging on the
src/util/virpci.c module because 4:util will be matched first.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Initially, update the UUID field to have the proper format, but
then also changed the type, id, and name fields.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When virDomainObjParseFile runs, it returns a locked @obj with
one reference. Rather than just use virObjectUnref to clean that
up, use virObjectEndAPI.
Signed-off-by: John Ferlan <jferlan@redhat.com>
If the virHashAddEntry fails, then we need to "careful" about
how we free the @obj. When virDomainObjParseFile returns there
is one reference and the object is locked, so use virDomainObjEndAPI
when done.
Add a virObjectRef in the error path for the second virHashAddEntry
call since it doesn't call virObjectRef, but virHashRemoveEntry
will call virObjectUnref because virObjectFreeHashData is called
when the element is removed from the hash table as set up in
virDomainObjListNew.
Signed-off-by: John Ferlan <jferlan@redhat.com>
If the virHashAddEntry fails, then we need to "careful" about
how we free the @vm. When virDomainObjNew returns there is one
reference and the object is locked, so use virDomainObjEndAPI
when done.
Add a virObjectRef in the error path for the second virHashAddEntry
call since it doesn't call virObjectRef, but virHashRemoveEntry
will call virObjectUnref because virObjectFreeHashData is called
when the element is removed from the hash table as set up in
virDomainObjListNew.
Eventually these paths should goto error and error should be changed
to use EndAPI as well, but that requires more adjustments to other
paths in the code to have a locked and ref counted @vm.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Now that support for the pcie-to-pci-bridge controller has
been implemented, adding the QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE
capability to the existing test is enough to cause the guest
to use pcie-to-pci-bridge instead of dmi-to-pci-bridge.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Both pcie-to-pci-bridge and dmi-to-pci-bridge can be used to
create a traditional PCI topology in a pure PCIe guest such as
those using the x86_64/q35 or aarch64/virt machine type;
however, the former should be preferred, as it doesn't need to
obey limitation of real hardware and is completely
architecture-agnostic.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1520821
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like the existing areMultipleRootsSupported, this will
allow us to change the results of the driver-agnostic PCI
address allocation logic based on whether the QEMU binary
supports certain features.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The new controller will not yet be used automatically by
libvirt, but at this point it's already possible to configure
a guest to use it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to add a similarly-named attribute later, and we'd
like to be consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This test shows what happens when you add a traditional PCI
device such as pci-serial to a pure PCIe machine type such
as aarch64/virt.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Instead of first listing the models on their own, and then
listing them again grouped by the libvirt release they were
introduced in, have a single list.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When preparing for migration, the libxl driver creates a new TCP listen
socket for the incoming migration by calling virNetSocketNewListenTCP,
passing the destination host name. virNetSocketNewListenTCP calls
virSocketAddrParse to check if the host name is a wildcard address, in
which case it avoids adding the AI_ADDRCONFIG flag to the hints passed to
getaddrinfo. If the host name is not an IP address, virSocketAddrParse
reports an error
error : virSocketAddrParseInternal:121 : Cannot parse socket address
'myhost.example.com': Name or service not known
But virNetSocketNewListenTCP succeeds regardless and the overall migration
operation succeeds.
Introduce virSocketAddrParseAny and use it when simply testing if a host
name/addr is parsable.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
