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

Modify the virsh man page to more accurately describe which values are
set by the virsh setmem and displayed by the virsh memtune or dominfo
based on the setmem command results.

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

According to the formatstorage.html description for <source> element
and "format" attribute: "All drivers are required to have a default
value for this, so it is optional."

As it turns out the disk backend did not choose a default value, so I
added a default of "msdos" if the source type is "unknown" as well as
updating the storage.html backend disk volume driver documentation to
indicate the default format is dos.

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

This patch resolves a situation where the same "<target dev='$name'...>"
can be used for multiple disks in the domain.

While the $name is "mostly" advisory regarding the expected order that
the disk is added to the domain and not guaranteed to map to the device
name in the guest OS, it still should be unique enough such that other
domblk* type operations can be performed.

Without the patch, the domblklist will list the same Target twice:

$ virsh domblklist $dom
Target     Source
------------------------------------------------
sda        /var/lib/libvirt/images/file.qcow2
sda        /var/lib/libvirt/images/file.img

Additionally, getting domblkstat, domblkerror, domblkinfo, and other block*
type calls will not be able to reference the second target.

Fortunately, hotplug disallows adding a "third" sda value:

$ qemu-img create -f raw /var/lib/libvirt/images/file2.img 10M
$ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sda
error: Failed to attach disk
error: operation failed: target sda already exists

$

BUT, it since 'sdb' doesn't exist one would get the following on the same
hotplug attempt, but changing to use 'sdb' instead of 'sda'

$ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sdb
error: Failed to attach disk
error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-1' for device

$

Since we cannot fix this issue at parsing time, the best that can be done so
as to not "lose" a domain is to make the check prior to starting the guest
with the results as follows:

$ virsh start $dom
error: Failed to start domain $dom
error: XML error: target 'sda' duplicated for disk sources '/var/lib/libvirt/images/file.qcow2' and '/var/lib/libvirt/images/file.img'

$

Running 'make check' found a few more instances in the tests where this
duplicated target dev value was being used. These also exhibited some
duplicated 'id=' values (negating the uniqueness argument of aliases) in
the corresponding .args file and of course the *xmlout version of a few
input XML files.

A disk using a source pool is listed as having a source '-' in domblklist
because it doesn't check the right XML syntax to find the source.

Add a check for "./source/volume" which is where the "path" (of sorts)
to the volume name is described.

The total NUMA memory consists of the sum of individual NUMA node memory
amounts.

NUMA enabled guest configuration explicitly specifies memory sizes for
individual nodes. Allowing the virDomainSetMemoryFlags API (and friends)
to change the total doesn't make sense as the individual node configs
are not updated in that case.

Forbid use of the API in case NUMA is specified.

The messages for currentMemory and memory were swapped.

Our documentation isn't 100% clear about hostdev 'managed' attribute usage,
because it only makes sense to use it with PCI devices, yet we format
this attribute to all hostdev devices. By adding a note into the docs,
we can possibly avoid confusion from customer's side and also avoid a solution
using ternary logic.

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

Commit 155ca616 added a error message
that skips initialization of the 'cmd' variable. Fortunately it was not
released.

If the domain is not running, the agent will not respond.
Do not even try.

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

Not just the DomainObj's private data.

This way checks requiring the job can be done in qemuDomainAgentAvailable.

The tool creating the image can get the capacity from the backing
storage. Just refresh the volume afterwards.

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

Add VIR_VOL_XML_PARSE_OPT_CAPACITY flag to virStorageVolDefParseXML.
With this flag, no error is reported when the capacity is missing
if there is a backing store.

This reverts commit f1856eb6.

Now that we can update capacity from image metadata,
we don't need to skip the update.

Instead of just looking at the output of fstat, call
virStorageFileGetMetadata to get the full capacity from
image headers.

Note that the capacity is probed unconditionally. The updateCapacity
bool parameter is ignored and will be removed in the following commit.

In virStorageVolCreateXML, add VIR_VOL_XML_PARSE_NO_CAPACITY
to the call parsing the XML of the new volume to make the capacity
optional.

If the capacity is omitted, use the capacity of the old volume.
We already do that for values that are less than the original
volume capacity.

Add VIR_VOL_XML_PARSE_NO_CAPACITY flag to the volume XML
parser. When set, it allows the capacity element to be omitted.

So we can allow omitting the capacity element if backing store is
present.

Allow the callers to pass down libvirt-internal flags.

Wire up VIR_CONNECT_BASELINE_CPU_MIGRATABLE to this
command line option.

Assume no features block migration.

Filter out non-migratable features if
VIR_CONNECT_BASELINE_CPU_MIGRATABLE was specified.

This flag for virConnectBaselineCPU will allow filtering out
CPU features that block migration from the result.

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

Instead of tracking the number of added parameters,
add a comma at the end of each one unconditionally
and trim the trailing one at the end.

If we combine the boot order on the command line with other
boot options, we prepend order= in front of it.

Instead of checking if the number of added arguments is between
0 and 2, separate the strings for boot order and options
and prepend boot order only if both strings are not empty.

This option is xenner-only (since commit b81a7ece),
and we dropped support for xenner in commit de9be0ab.

It was only supported by xenner (since commit 763a59d8),
for which we removed support in commit de9be0ab.

Remove the code generating this command line option,
refuse to parse it and delete the outdated tests.

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

As reported on the libvirt-users list [1], there's new web
application called mist.io which uses libvirt as one of its
backends. Lets add it into our list of libivrt based
applications.

1: https://www.redhat.com/archives/libvirt-users/2015-February/msg00096.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit cf2d4c60 used a logical or instead of bitwise or,
effectively passing 1, that is VIR_DOMAIN_XML_INACTIVE.

This was caught by a warning when building with clang.

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

Commit 69929941 started filling the listen attribute
of the parent <graphics> elements from type='network' listens.

When this XML is passed to UpdateDevice, parsing fails:
XML error: graphics listen attribute 10.20.30.40 must match
address attribute of first listen element (found none)

Ignore the address in the parent <graphics> attribute
when no type='address' listens are found,
the same we ignore the address for the <listen> subelements
when parsing inactive XML.

The gluster volume name extraction code was copied from the XML parser
without changing the VIR_ERR_XML_ERROR error code. Use
VIR_ERR_CONFIG_UNSUPPORTED instead.

Similar to commit fdb80ed4 libvirtd
would crash if a gluster URI without path would be used in the backing
chain of a volume. The crash happens in the gluster specific part of the
parser that extracts the gluster volume name from the path.

Fix the crash by checking that the PATH is NULL.

This patch does not contain a test case as it's not possible to test it
with the current infrastructure as the test suite would attempt to
contact the gluster server in the URI. I'm working on the test suite
addition but that will be post-release material.

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

In virNetworkDHCPHostDefParseXML an error is reported
when partialOkay == true, and none of ip, mac, name
were supplied.

Add the missing goto and error out in this case.

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

We already check whether the host id is valid or not, add a jump
to forbid invalid host id.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Commit f7afeddc added code to report to systemd an array of interface
indexes for all tap devices used by a guest. Unfortunately it not only
didn't add code to report the ifindexes for macvtap interfaces
(interface type='direct') or the tap devices used by type='ethernet',
it ended up sending "-1" as the ifindex for each macvtap or hostdev
interface. This resulted in a failure to start any domain that had a
macvtap or hostdev interface (or actually any type other than
"network" or "bridge").

This patch does the following with the nicindexes array:

1) Modify qemuBuildInterfaceCommandLine() to only fill in the
nicindexes array if given a non-NULL pointer to an array (and modifies
the test jig calls to the function to send NULL). This is because
there are tests in the test suite that have type='ethernet' and still
have an ifname specified, but that device of course doesn't actually
exist on the test system, so attempts to call virNetDevGetIndex() will
fail.

2) Even then, only add an entry to the nicindexes array for
appropriate types, and to do so for all appropriate types ("network",
"bridge", and "direct"), but only if the ifname is known (since that
is required to call virNetDevGetIndex().

Previously this function relied on having ATTRIBUTE_NONNULL(1) in its
prototype rather than explicitly checking for a null
ifname. Unfortunately, ATTRIBUTE_NONNULL is just a hint to the
optimizer and code analyzers like Coverity, it doesn't actually check
anything at execution time, so the result was possible warnings from
Coverity, along with the possibility of null dereferences when ifname
wasn't available.

This patch removes the ATTRIBUTE_NONNULL from the prototype, and
checks ifname inside the function, logging an error if it's NULL (once
we've determined that the user really is trying to set a bandwidth).

libvirt was unconditionally calling virNetDevBandwidthClear() for
every interface (and network bridge) of a type that supported
bandwidth, whether it actually had anything set or not. This doesn't
hurt anything (unless ifname == NULL!), but is wasteful.

This patch makes sure that all calls to virNetDevBandwidthClear() are
qualified by checking that the interface really had some bandwidth
setup done, and checks for a null ifname inside
virNetDevBandwidthClear(), silently returning success if it is null
(as well as removing the ATTRIBUTE_NONNULL from that function's
prototype, since we can't guarantee that it is never null,
e.g. sometimes a type='ethernet' interface has no ifname as it is
provided on the fly by qemu).