The wiki page we currently link to is just a redirect for
back compat.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The two sides of a PTY can be referred to as primary and secondary
TTYs.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When querying QEMU we have to iterate over two nested sets
of CPUs. The terms "main vcpu" and "sub vcpu" are a good
representation.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The two sides of a PTY can be referred to as primary and  secondary
TTYs.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Network interfaces are simply attached to a bridge device.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Network interfaces are simply attached to a bridge device.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term "ignored" is a better choice for the filtering performed
on devices from udev.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This new naming matches the terminology used in the error
messages that the callers report.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term is redundant in the context used.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When listing CPU models, we need to filter the data based on sets
of permitted and forbidden CPU models.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term "access control list" better describes the concept involved.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term "access control list" better describes the concept involved.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term "access control list" better describes the concept involved.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The term "permitted list" is a better choice for the filtering
logic applied.
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

CentOS does not have the cppi package, so some code style checks are
skipped. Switch to a openSUSE image to do the code style checks.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

When parsing domain XML post parse callbacks are run and one of
them might try and call API from a non-hypervisor driver (e.g.
just like qemuDomainDeviceNetDefPostParse() is doing - it calls a
network API). To avoid this in the test suite, set dummy drivers,
which renders all non-hypervisor APIs return error.

This mimics what qemuxml2argvtest does.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

When using the DO_TEST_PARSE_ERROR() macro, a failure to parse the input
file is considered a successful test. However, if the input file is
totally missing, that should be distinguished from a parsing error and
not be treated as a test success.

The function virDomainDefParseFile() simply returns NULL for any parse
failure, including a missing file. So we need to explicitly check
whether the file exists first, and fail the test if it is missing.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

Although a ramfb video device is not a PCI device, we don't currently
report an error for ramfb device definitions containing a PCI address.
However, a guest configured with such a device will fail to start:

    # virsh start test1
    error: Failed to start domain test1
    error: internal error: qemu unexpectedly closed the monitor: 2020-06-16T05:23:02.759221Z qemu-kvm: -device ramfb,id=video0,bus=pcie.0,addr=0x1: Device 'ramfb' can't go on PCIE bus

A better approach is to reject any device definitions that contain PCI
addresses.  While this is a change in behavior, any existing
configurations were non-functional.

https://bugzilla.redhat.com/show_bug.cgi?id=1847259Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

A few commits back (in v6.4.0-131-gbdb8f2e4) the post parse
function for domain interface was changed so that it doesn't fill
in model for hostdev types of interfaces (including network type
interfaces which would end up hostdevs).

While the idea is sound, the execution can be a bit better:
virDomainNetResolveActualType() which is used to determine
runtime type of given interface is heavy gun - it connects to
network driver, fetches network XML, parses it. This all is
followed by check whether the interface doesn't already have
model set (from domain XML).

If we switch the order of these two checks then the short circuit
evaluation will ensure the expensive check is done only if really
needed.

This commit in fact fixes qemuxml2xmltest which due to lacking
fake network driver tries to connect to network:///session and
start the virtnetworkd. Fortunately, because of
v6.3.0-25-gf28fbb05 it fails to do so and
virDomainNetResolveActualType() returns -1. The only reason we
don't see the test failing is because our input XMLs have model
and thus we are saved by the latter (now former) check.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NLaine Stump <laine@redhat.com>

All targets get pip3, which is now part of the base system, and
the number of native packages included in the MinGW containers is
significantly reduced.

The corresponding libvirt-ci commit is 4ff697ba0b5d.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

There were two upstream issues filed for the problem so it's worth
mentioning.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

oVirt does merge images out of libvirt in some cases. Add docs outlining
how it's done from a high level.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Simplify the docs and reduce maintenance burden by just describing the
algorithm by a pseudo-language. Users are encouraged to use libvirt
anyways and projects such as oVirt which do some management of storage
themselves are unlikely to use bash anyways.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Define what users should look for when wanting to manipulate bitmaps
themselves.

Later on a patch will turn the bash algorithms into pseudocode for
simplicity.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Add a section that outlines usage of tools to handle bitmaps and
introduce terms corresponding to the output of qemu-img to be used in
further sections.

With this we can simplify the section about checking bitmap health as we
don't have to explain the qemu-img output but can refer to the newly
defined terms.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Emphasize what needs to happen and also that creating a snapshot doesn't
create the appropriate bitmaps. Also mention that granularity is kept.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Make it obvious what's meant by 'overlay' and 'backing image' for sake
of extension of the document.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Until recently, an <interface type='network'> would automatically be
assigned model "rtl8139", which in turn would lead to the device being
assigned a PCI address on a conventional PCI controller (i.e. a
pcie-to-pci-bridge). If the network was a typical Linux host
bridge-based network that used an emulated device, this would be
appropriate, since the guest actually would get an emulated rtl8139
NIC, and that device is a conventional PCI device.

However, if the network being used was a pool of hostdev devices, the
guest would get an actual PCIe network device assigned from the host
via VFIO; while the interface model in that case is irrelevant for the
QEMU commandline to assign the device, the PCI address would have
already been assigned prior to runtime, so the address assignment
would be done based on the model='rtl8139' - a conventional PCI
device. VFIO assignment of a PCIe device to a conventional PCI slot
works, but we would rather have these devices in a PCIe slot.

Since commit bdb8f2e4, if <interface type='network'> points to a
etwork that is a pool of hostdev devices, the interface model will be
_unset_ by default. This patch uses that information when deciding
what type of slot to assign to the device: since all hostdev network
interfaces are SR-IOV VFs, and *all* SR-IOV network cards are PCIe, it
is safe to assume that the VFs are PCIe and we should assign then to a
PCIe slot in the guest.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

All the domain job related APIs were present in `qemu_domain.c`
along with the other domain APIs. In this patch, we move all the
qemu domain job APIs into a separate file.

Also, in this process, `qemuDomainTrackJob()`,
`qemuDomainFreeJob()`, `qemuDomainInitJob()` and
`qemuDomainObjSaveStatus()` were converted to a non-static
funciton and exposed using `qemu_domain.h`.
Signed-off-by: NPrathamesh Chavan <pc44800@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In functions `qemuDomainObjInitJob`, `qemuDomainObjResetJob`,
`qemuDomainObjResetAgentJob`, `qemuDomainObjResetAsyncJob`,
`qemuDomainObjFreeJob`, `qemuDomainJobAllowed`,
`qemuDomainNestedJobAllowed` we avoid sending the complete
qemuDomainObjPrivatePtr as parameter and instead just send
qemuDomainJobObjPtr.

This is done in a effort to separating the qemu-job APIs into
a spearate file.
Signed-off-by: NPrathamesh Chavan <pc44800@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

For some minimal OS like fedora cloud image, the make is not installed
by default.
Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Some functions or code paths that may fail don't report error
(e.g. when acquiring PID file fails) leading to a silent quit
of the leaseshelper. This makes it super hard for us and users
to debug what is happening. Fortunately, dnsmasq captures both
stdout and stderr so we can write an error message there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

On a DHCP transaction, dnsmasq runs our leases helper which
updates corresponding JSON files. While one dnsmasq won't run the
leaseshelper in parallel, two dnsmasqs (from two distinct
networks) might. To avoid corrupting JSON file, the leaseshelper
acquires PID file first. Well, the way it's acquiring it is not
ideal - it calls virPidFileAcquirePath(wait = false); which
means, that either it acquires the PID file instantly or returns
an error and does not touch the JSON at all. This in turn means
that there might be a leases record missing. With wait = true,
this won't happen.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1840307Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The "virsh domcapabilities --arch ppc64" command will fail with no
error message set if qemu-system-ppc64 is not currently installed.

This is because virQEMUCapsCacheLookup() does not report any error
message if not capabilities can be obtained from the cache. Almost
all methods calling this expected an error to be set on failure.

Once that's fixed though, we see a further bug which is that
virQEMUCapsCacheLookupDefault() is passing a NULL binary path to
virQEMUCapsCacheLookup(), so we need to catch that too.
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

$ git log --committer=ptoscano@redhat.com --pretty=oneline | wc -l
11
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Move people who currently do not have commit access:
  https://gitlab.com/libvirt/libvirt/-/project_members
to the 'previous maintainers' section.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

It's possible to use ramfb as the boot display of an assigned vgpu
device. This was introduced in 4b95738c, but unfortunately the attribute
was not formatted into the xml output for such a device. This patch
fixes that oversight and adds a xml2xml test to verify proper behavior.

https://bugzilla.redhat.com/show_bug.cgi?id=1847791Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The XML format used for QEMU capabilities is not required to be
stable across releases, as we invalidate the cache whenever the
libvirt binary changes.

We none the less always try to parse te entire XML file before
we do any validity checks. Thus if we change the format of any
part of the data, or change permitted values for enums, then
libvirtd logs will be spammed with errors.

These are not in fact errors, but an expected scenario.

This change makes the loading code validate the cache timestamp
against the libvirtd timestamp immediately. If they don't match
then we stop loading the rest of the XML file.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDmitry Nesterenko <dmitry.nesterenko@virtuozzo.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDmitry Nesterenko <dmitry.nesterenko@virtuozzo.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>