Pass the data by reference rather than everything on the stack.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We use the "vir" prefix pretty consistently in our
APIs, both external and internal, which made these
macros stood out.

For native gluster pools the <dir> field denotes a directory inside the
pool. For the actual pool name the <name> field has to be used.

Use the relative lookup specifier rather than the global one. Otherwise
only the first name would be looked up. Add a test case to cover the
scenario.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436574

Add a test program called virstorageutiltest and test the gluster pool
detection code.

To allow testing of the algorithm, split out the extractor into a
separate helper.

The native gluster pool source list data differs from the data used for
attaching gluster volumes as netfs pools. Currently the only difference
was the format. Since native pools don't use it and later there will be
more differences add a more deterministic way to switch between the
types instead.

Similar to commit b202c39a ignore the warning that breaks the build
with clang:
util/virnetlink.c:365:52: error: cast from 'char *' to 'struct nlmsghdr *'
 increases required alignment from 1 to 4 [-Werror,-Wcast-align]
        for (msg = resp; NLMSG_OK(msg, len); msg = NLMSG_NEXT(msg, len)) {
                                                   ^~~~~~~~~~~~~~~~~~~~
/usr/include/linux/netlink.h:87:7: note: expanded from macro 'NLMSG_NEXT'
         (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len)))
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Make sure that non-hotpluggable vcpus stay clustered at the beginning
after modifying persistent definition.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437010

Validate that users don't try to disable vcpu 0.

Vcpu order is required to stay sequential. Clear the order on cpu
coldplug to avoid issues with removing vcpus out of sequence.

'next' is declared as 'ssize_t' so use '%zd'

Buggy condition meant that vcpu0 would not be iterated in the checks.
Since it's not hotpluggable anyways we would not be able to break the
configuration of a live VM.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013

Similar to commit c3c2cc65, use a literal newsline instead of \n
inside the brackets.

Like all devices, add the 'id' option for mdevs as well. Patch also
adjusts the test accordingly.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438431Signed-off-by: NErik Skultety <eskultet@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1371892

The 'capacity' value (e.g. guest logical size) for a LUKS volume is
smaller than the 'physical' value of the file in the file system, so
we need to account for that.

When peeking at the encryption information about the volume add a fetch
of the payload_offset which is described as the offset to the start of
the volume data (in 512 byte sectors) in QEMU's QCryptoBlockLUKSHeader.

Then adjust the ->capacity appropriately when we determine that the
volume target encryption has a payload_offset value.

Add check for more than one RTA_OIF, even though this is rather
unlikely.

Get rid of the buggy switch / break as this code won't need to
handle more attributes.

Use VIR_WARNINGS_NO_CAST_ALIGN to fix impossible to fix
util/virnetdevip.c:560:17: error: cast increases required alignment of target type [-Werror=cast-align]

Make sure every combination of ACPI and UEFI works, or fails to
work, as expected.

Depending on the architecture, requirements for ACPI and UEFI can
be different; more specifically, while on x86 UEFI requires ACPI,
on aarch64 it's the other way around.

Enforce these requirements when validating the domain, and make
the error message more accurate by mentioning that they're not
necessarily applicable to all architectures.

Several aarch64 test cases had to be tweaked because they would
have failed the validation step otherwise.

So far, libvirt has assumed that only x86 supports ACPI,
but that's inaccurate since aarch64 supports it too.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1429509

Now that the NO_ACPI and NO_HPET capabilities are set
automatically by virQEMUCapsInitQMPBasicArch() if
appropriate for the architecture, they shouldn't be
used manually to avoid masking bugs.

The capabilities used in test cases should match those used
during normal operation for the tests to make any sense.

This results in the generated command line for a few test
cases (most notably non-x86 test cases that were wrongly
assuming they could use -no-acpi) changing.

Instead of having a single function that probes the
architecture from the monitor and then sets a bunch of
basic capabilities based on it, have a separate function
for each part: virQEMUCapsInitQMPArch() only sets the
architecture, and virQEMUCapsInitQMPBasicArch() only sets
the capabilities.

This split will be useful later on, when we will want to
set basic capabilities from the test suite without having
to go through the pain of mocking the monitor.

Creating dummy <change> elements was a workaround for the
HTML DTD not allowing empty <ul> elements, but we can do
better by tweaking the the XSLT stylesheet.

Now that the source file is validated against a schema that
only allows the <code> HTML tag to be used, we can rely on
that assumption to simplify our XSLT stylesheet.

If a transient storage pool is deemed inactive after libvirtd restart it
would not be deleted from the list. Reuse virStoragePoolUpdateInactive
along with a refactor necessary to properly update the state.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1242801

After a pool is made inactive the definition objects need to be updated
(if a new definition is prepared) and transient pools need to be
completely removed. Split out the code doing these steps into a separate
function for later reuse.

When registering a storage poll backend, the code would use
virStorageTypeToString instead of virStoragePoolTypeToString. The
following message would be logged:

virDriverLoadModuleFunc:71 : Lookup function 'virStorageBackendSCSIRegister'
virStorageBackendRegister:174 : Registering storage backend '(null)'

Since this file gets changed (and broken) rather often, introduce a
schema file so that the test suite can validate it.

Add stricter rules for the news file and fix offending entries.

Sometimes it may be desired to validate individual files against a
schema. Refactor the data structures to unify them and introduce a new
macro DO_TEST_FILE(schema, xmlfile) which will test the XML file against
the given schema file.

Currently, if we want to zero out disk source (e,g, due to
startupPolicy when starting up a domain) we use
virDomainDiskSetSource(disk, NULL). This works well for file
based storage (storage type file, dir, or block). But it doesn't
work at all for other types like volume and network.

So imagine that you have a domain that has a CDROM configured
which source is a volume from an inactive pool. Because it is
startupPolicy='optional', the CDROM is empty when the domain
starts. However, the source element is not cleared out in the
status XML and thus when the daemon restarts and tries to
reconnect to the domain it refreshes the disks (which fails - the
storage pool is still not running) and thus the domain is killed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

The virMacMap module is there for dumping [domain, <list of is
MACs>] pairs into a file so that libvirt_guest NSS module can use
it. Whenever a interface is allocated from network (e.g. on
domain<F2> startup or NIC hotplug), network is notified and so is
virMacMap module subsequently. The module update functions
networkMacMgrAdd() and networkMacMgrDel() gracefully handle the
case when there's no module. The problem is, the module is
created if and only if network is freshly started, or if the
daemon restarts and network previously had the module.

This is not very user friendly - if users want to use the NSS
module they need to destroy their network and bring it up again
(and subsequently all the domains using it).

One disadvantage of this approach implemented here is that one
may get just partial results: any already running network does
not record mac maps, thus only newly plugged domains will be
stored in the module. The network restart scenario is not touched
by this of course. But one can argue that older libvirts had
never recorded the mac maps anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far our code is full of the following pattern:

  dom = virGetDomain(conn, name, uuid)
  if (dom)
      dom->id = 42;

There is no reasong why it couldn't be just:

  dom = virGetDomain(conn, name, uuid, id);

After all, client domain representation consists of tuple (name,
uuid, id).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

* docs/news.xml: update for release
* po/*.po*: regenerated

USB tables -> USB tablet.

that is: s/hyperyVerifyResponse/hypervVerifyResponse/