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: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel 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: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel 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: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel 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: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel 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: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel 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: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NErik Skultety <eskultet@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: NErik 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: NErik Skultety <eskultet@redhat.com>

This was some copy-paste leftover.
Signed-off-by: NErik 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: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NErik 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: NJohn Ferlan <jferlan@redhat.com>

Create a common helper to add an object to the locked domain
objlist hash tables and use it.
Signed-off-by: NJohn 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: NJohn 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: NJohn Ferlan <jferlan@redhat.com>

This variable is not actually used in the function. Especially
after 31869efe.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since its introduction in 5d5c732d it has been never used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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=1520821Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We're going to add a similarly-named attribute later, and we'd
like to be consistent.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

s/netork/network/
Signed-off-by: NJim Fehlig <jfehlig@suse.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: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>