Rather than have virCommandRun just spit out the error, allow callers
to decide to pass the exitstatus so the caller can make intelligent
decisions based on the error.

(cherry picked from commit 8b104947)

Some of the test configuration files in tests/xlconfigdata
use the old qemu-dm as the emulator. Many of the configuration
features tested (spice, rbd, multi-usb) are not even usable with
the old qemu. Change these files to use the new qemu-xen (also
known as qemu upstream) emulator.

Note: This change fixes xlconfigtest failures when the old
qemu is actually installed on the system. During device post
parse, the libxl driver attempts to invoke the emulator to
determine if it is the old or new qemu so it can properly set
video RAM defaults. With the old qemu installed, the default
video RAM was set differently than the expected value.
Changing all the test data files to use qemu-xen ensures
predictable results wrt default video RAM size.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit b90c4b5f)

When probing the <emulator> with '-help' to determine if
it is the old qemu, errors are reported if the emulator
doesn't exist

libvirt:  error : internal error: Child process
(/usr/lib/xen/bin/qemu-dm -help) unexpected exit status 127:
libvirt:  error : cannot execute binary /usr/lib/xen/bin/qemu-dm:
No such file or directory

Avoid the probe if the specified emulator doesn't exist,
squelching the error. There is no behavior change since
libxlDomainGetEmulatorType() would return
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN if the probe failed
via virCommandRun().
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit 400e716d)

My commit 3e428670 started filling out the video size in post-parse,
but did not adjust the tests.

(cherry picked from commit 96b21fb0)

Move filling out the default video (v)ram to DeviceDefPostParse.

This means it can be removed from virDomainVideoDefParseXML
and qemuParseCommandLine. Also, we no longer need to special case
VIR_DOMAIN_VIRT_XEN, since the per-driver callback gets called
before the generic one.

(cherry picked from commit 538012c8)

Commit 6879be48 moved adding of an implicit video device after XML
parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
called to set the default vram when adding an implicit device.
Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
default vram, but it returns 0 if the domain virtType is
VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
results in

error: unsupported configuration: videoram must be at least 4MB for CIRRUS

The default vram setting for Xen HVM domains depends on the device
model used (qemu-xen vs qemu-traditional), hence setting the
default is deferred to libxlDomainDeviceDefPostParse().

Call the device post-parse callback even for implicit video,
to fill out the default vram even for VIR_DOMAIN_VIRT_XEN.

https://bugzilla.redhat.com/show_bug.cgi?id=1334557Most-of-commit-message-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit 3e428670)

Future commit will call DeviceDefPostParse on a device auto-added
in DomainDefPostParse.

(cherry picked from commit e4d131b8)

(cherry picked from commit 12786889)

Return early if there is nothing to do.

(cherry picked from commit 1485be17)

Commin 36785c7e refactored the code for input devices but introduced a
bug where we removed all keyboard from migratable XML.  We have to
remove only implicit keyboards like PS2 or XEN.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Commit 1d440008 added some code that was not indented properly
and broke syntax-check. Fix it.

(cherry picked from commit a528ae7f)

Previous commit moved some lists out of the -devel package
and into the -docs package

  commit feffcc03
  Author: Cole Robinson <crobinso@redhat.com>
  Date:   Wed Apr 13 10:37:42 2016 -0400

    spec: Only pull in API docs with -devel package

What was not realized is that the rule 'libvirt-docs/*'
and ' docs/*.html docs/html docs/*.gif' actually point
to the exact same content. ie, we had previously included
the website HTML in *both* the -docs and -devel packages.

So this change ended up listing the files twice, which
caused RPM to print a load of warnings:

warning: File listed twice: /usr/share/doc/libvirt-docs/html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/32favicon.png
warning: File listed twice: /usr/share/doc/libvirt-docs/html/404.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/acl.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/aclpolkit.html
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d6c25c34)

We will segfault of a daemon reload picks up a new network config
that needs to be autostarted. We shouldn't be passing NULL for
network_driver here. This seems like it was missed in the larger
rework in commit 1009a61e

(cherry picked from commit 26af7e4e)

The default USB controller is not sent to destination as the older versions
of libvirt(0.9.4 or earlier as I see in commit log of 409b5f54) didn't
support them. For some archs where the support started much later can
safely send the USB controllers without this worry. So, send the controller
to destination for all archs except x86. Moreover this is not very applicable
to x86 as the USB controller has model ich9_ehci1 on q35 and for pc-i440fx,
there cant be any slots before USB as it is fixed on slot 1.

The patch fixes a bug that, if the USB controller happens to occupy
a slot after disks/interfaces and one of them is hot-unplugged, then
the default USB controller added on destination takes the smallest slot
number and that would lead to savestate mismatch and migration
failure. Seen and verified on PPC64.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
(cherry picked from commit 192a53e0)

Add ULL suffix to all related operands of << or shift will give
all zeros instead of correct mask.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
(cherry picked from commit 4d28d093)

Similarly to what commit 71408079 did with some internal paths,
clear vnc socket paths that were generated by us.  Having such path in
the definition can cause trouble when restoring the domain.  The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.

To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated.  And mark it as autogenerated
if it already exists and we're parsing live XML.

Best viewed with '-C'.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 55320c23)

Instead of setting the default qemu stdio logging approach in
virQEMUDriverConfigLoadFile set it in virQEMUDriverConfigNew so that
it's properly set even when the config is not present.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1325075
(cherry picked from commit 63e2b766)

Introduced by commit 15ad2ecf.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit d3d4fb4b)

If libvirt-daemon-config-network is installed while libvirtd is already
running, the daemon doesn't notice the network. Users then have to
manually restart libvirtd (or reboot) to pick up the network.

Instead let's trigger a daemon restart when the package is first installed.
Then the default network is available immediately if libvirtd was already
running.

https://bugzilla.redhat.com/show_bug.cgi?id=867546
(cherry picked from commit 1d440008)

This error message was too specific, based on the incorrect assumption
that any error was cause by auto-added bridges:

  failed to create PCI bridge on bus 2: too many devices
  with fixed addresses

In practice you can't know if a bridge with an index <= the bus it's
connecting to was added automatically, or if it was a mistake in
explicit config, and the auto-add problem is going to be dealt with in
a different way in an upcoming patch. The new message is this:

  PCI Controller at index 1 (0x01) has "
  bus='0x02', but bus must be <= index

(note that index is given in both decimal and hex because it is
formatted as decimal in the XML, but bus is formatted as hex, and
displaying the hex value of index makes it easier to see the problem
when index > 9 (which will often be the case with PCIe, since most
controllers only have a single port, not 32 slots as with standard
PCI)).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004593
(cherry picked from commit ff212622)

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1329819
(cherry picked from commit 3a703b81)

QEMU_BLOCK_IOTUNE_MAX is the maximum inclusively, so let's modify the
message so it makes sense.

https://bugzilla.redhat.com/show_bug.cgi?id=1329041Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 72c313bc)

Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45

However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:

http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html

Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely

https://bugzilla.redhat.com/show_bug.cgi?id=1074464
(cherry picked from commit 67f2b727)

We presently don't give any indication if the VirtualBox version
isn't in our support whitelist.

(cherry picked from commit 18644491)

The values are currently limited to LLONG_MAX which causes some
problems.  QEMU conveniently changed their maximum to 1e15 (1 PB) which
is enough for some time and we need to adapt to that so that we don't
throw "Unknown error" messages.  Strictly limiting these values actually
fixes some corner case values (off-by-one checks in QEMU probably).

Since values out of the new specified range do not overflow anything,
change the type of error as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 2d04f6de)

$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf

Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing

https://bugzilla.redhat.com/show_bug.cgi?id=1151409
(cherry picked from commit 3cc2a9e0)

According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:

 dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0

The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033739
(cherry picked from commit bf3d9f30)

FD passing APIs like CreateXMLWithFiles or OpenGraphicsFD will leak
file descriptors. The user passes in an fd, which is dup()'d in
virNetClientProgramCall. The new fd is what is transfered to the
server virNetClientIOWriteMessage.

Once all the fds have been written though, the parent msg->fds list
is immediately free'd, so the individual fds are never closed.

This closes each FD as its send to the server, so all fds have been
closed by the time msg->fds is free'd.

https://bugzilla.redhat.com/show_bug.cgi?id=1159766
(cherry picked from commit 5ba48584)

My commit 0d157957 crashes on a URI without a scheme, like via
'virsh --connect frob'

Add a check on uri->server too while we are at it, and centralize
them all

(cherry picked from commit f1bae376)

My commit 6879be48 moved the addition of the implicit video device
from the XML parser to the PostParse function, but did not regenerate
all the tests.

(cherry picked from commit 4b35a715)

virsh vol-clone is expected to clone a volume within a single
pool; it doesn't work for cloning across pools. Clarify the docs

https://bugzilla.redhat.com/show_bug.cgi?id=1103714
(cherry picked from commit 2f1dc3de)

VIR_ERR_NO_SUPPORT maps to the error string

    this function is not supported by the connection driver

and is largely only used for when a driver doesn't have any
implementation for a public API. So its usage with invalid
net-update requests is a bit out of place. Instead use
VIR_ERR_OPERATION_UNSUPPORTED which maps to:

    Operation not supported

And is what qemu's hotplug routines use in similar scenarios

(cherry picked from commit cdb4caac)

This reverts commit 1e9808d3.

We shouldn't advertise libvirtd.socket activation, since currently
it means VM/network/... autostart won't work as expected.

We tried to find a middle ground by installing the config file without
an [Install] section, since systemd won't allow .socket to be enabled
without one... or at least it did do that; presently on f24 it allows
activating the socket quite happily. This also caused user confusion[1]

Just remove the socket file. I've filed a new RFE to track coming up
with a solution to the autostart problem[2], we can point users at that
if there's more confusion:

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1279348
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1326136

(cherry picked from commit 3b9100a4)

It's a fairly common error that a user tries to connect to a URI
like qemu://system or qemu://session (missing a slash). This errors
like:

$ virsh --connect qemu://session
error: failed to connect to the hypervisor
error: Unable to resolve address 'session' service '16514': No address associated with hostname

If you already know that the standard qemu URI has 3 slashes, that
error will make it obvious enough. But new user's may not get it.
There's even a RHEL support page explicitly mentioning it!:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Troubleshooting-Common_libvirt_errors_and_troubleshooting.html

Catch this error early in libvirt.c virConnectOpen for qemu (and vbox
which has similar rules

https://bugzilla.redhat.com/show_bug.cgi?id=1038304
(cherry picked from commit 0d157957)

It isn't implemented and does not work:

error: internal error: guest failed to start: /usr/lib/libvirt/libvirt_lxc: option '--veth' requires an argument
syntax: /usr/lib/libvirt/libvirt_lxc [OPTIONS] ...

We previously threw an explicit error, but this changed in
22cff52a , which I suspect was
untested for LXC

(cherry picked from commit 27f2b747)

While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).

Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.

So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.

Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
(cherry picked from commit dd140028)

virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:

We have only 2 keys
A  (multiples allowed)
B  (multiples NOT allowed)

We are given the following list of parameters to check:
A
A
B

If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"

This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.

In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.

virsh migrate --live guestname --copy-storage-all
              --migrate-disks vdb,vdc,vdd,vde,vdf
              qemu+ssh://dsthost/systemSigned-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: NEric Farman <farman@linux.vnet.ibm.com>
(cherry picked from commit 0e570a6a)

Commit id '4b75237f' seems to have triggered Coverity into finding
at least one memory leak in xen_xl.c for error path for cleanup where
the listenAddr would be leaked. Reviewing other callers, it seems that
qemu_parse_command.c would have the same issue, so just it too.

(cherry picked from commit 727a3c58)

To ensure the libvirt libxl driver will build with future versions
of Xen where the libxl API may change in incompatible ways,
explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
does use new libxl APIs that have been added since Xen 4.2, but
currently it does not make use of any changes made to existing
APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
The version can be bumped if/when the libxl driver consumes the
changed APIs.

Further details can be found in the following discussion thread

https://www.redhat.com/archives/libvir-list/2016-April/msg00178.htmlSigned-off-by: NJim Fehlig <jfehlig@suse.com>
(cherry picked from commit e7440656)