We have two different places that needs to be updated while touching
code for allocation spice ports.  Add a bool option to
'qemuProcessSPICEAllocatePorts' function to switch between true and fake
allocation so we can use this function also in qemu_driver to generate
native domain definition.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>

Acked-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>

In commit edd1295e I've introduced an
XML element that allows to configure state of the network interface
link. Somehow the RNG schema hunk ended up in a weird place in the
network schema definition. Move it to the right place and add a test
case.

Note that the link state is set up via the monitor at VM startup so I
originally didn't think of adding a test case.

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

Since adding the support for scheduler policy settings in commit
8680ea97, there are two enums with the same information.  That was
caused by rewriting the patch since first draft.

Find out thanks to clang, but there was no impact whatsoever.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The problem here was that when opening a channel, we were checking
whether the channel given is alias (can't be NULL for running domain) or
it's name, which can be NULL (for example with spicevmc).  In case of
such domain qemuDomainOpenChannel() made the daemon crash.
STREQ_NULLABLE() is safe to use since the code in question is wrapped in
"if (name)" and is more readable, so use that instead of checking for
non-NULL "vm->def->channels[i]->target.name".
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Add to the man page a more complete description of what exactly the
command expects on input and will return on output based on what is
currently supported.

Perhaps missing findPoolSources implementations are backends for
sheepdog and rbd.  Also missing any backend is zfs.

The virStorageBackendISCSIFindPoolSources API only needs the 'host' name
in order to discover iSCSI pools, it returns the various device paths.
On input, it's also possible to further restrict a search by providing the
port attribute for the host element and the (undocumented) initiator element.

For example:

$  virsh find-storage-pool-sources-as iscsi
error: Failed to find any iscsi pool sources
error: invalid argument: hostname and device path must be specified for iscsi sources

$ virsh find-storage-pool-sources-as iscsi 192.168.122.1
<sources>
  <source>
    <host name='192.168.122.1' port='3260'/>
    <device path='iqn.2013-12.com.example:iscsi-chap-lclpool'/>
  </source>
</sources>

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