Fedora now ships edk2 firmware in its official repos, so adapt
the nvram path list to match. Eventually we can remove the nightly
links as well once some integration kinks have been worked out,
and documentation updated.

Move the macro building into the %build target, which lets us
build up a shell variable and make things a bit more readable

https://bugzilla.redhat.com/show_bug.cgi?id=1335395
(cherry picked from commit e9ef4dfa)

Use the detected tray presence flag to trigger the tray waiting code
only if the given storage device in qemu reports to have a tray.

This is necessary as the floppy device lost it's tray as of qemu commit:

commit abb3e55b5b718d6392441f56ba0729a62105ac56
Author: Max Reitz <mreitz@redhat.com>
Date:   Fri Jan 29 20:49:12 2016 +0100

    Revert "hw/block/fdc: Implement tray status"

(cherry picked from commit 72a7ff6b)

Commit 1fad65d4 used a really big hammer
and overwrote the error message that might be reported by qemu if the
tray is locked. Fix it by reporting the error only if no error is
currently set.

Error after commit mentioned above:
error: internal error: timed out waiting for disk tray status update

New error:
error: internal error: unable to execute QEMU command 'eject': Tray of
device 'drive-ide0-0-0' is not open

(cherry picked from commit 2e75da42)

The code grew rather convoluted. Extract it to a separate function.

(cherry picked from commit 0aa19f35)

If we exceed the timeout waiting for the tray status to change,
we don't report an error. Fix it

(cherry picked from commit 1fad65d4)

If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts
to change media would attempt to re-eject the tray even if it wouldn't
be notified when the tray opened. Add a capability bit and skip retrying
for old qemus.

(cherry picked from commit 833ae6b4)

Extract information for all disks and update tray state and source only
for removable drives. Additionally store whether a drive is removable
and whether it has a tray.

(cherry picked from commit 894dc85f)

Move it to a more sane place since it's refreshing data about disks.

(cherry picked from commit d9bee413)

Extract whether a given drive has a tray and whether there is no image
inserted.

Negative logic for the image insertion is chosen so that the flag is set
only if we are certain of the fact.

(cherry picked from commit f1690dc3)

(cherry picked from commit 5f963d89)

Empty floppy drives start with tray in "open" state and libvirt did not
refresh it after startup. The code that inserts media into the tray then
waited until the tray was open before inserting the media and thus
floppies could not be inserted.

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

No longer necessary to have it, so remove it.

(cherry picked from commit 027986f5)

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

Instead of disabling auto-login of all scsi targets (even those
that do not "belong" to libvirt), use iscsiadm's "--op nonpersistent"
during discovery of iSCSI targets (e.g. "iscsiadm --mode discovery
--type sendtargets") in order to avoid the node database being altered
which led to the need for the "large hammer" approach taken by
commit id '3c12b654'.

This commit removes the virISCSITargetAutologin adjustment (eg. the setting
of node.startup to "manual"). The iscsiadm command has supported this mode
of operation as of commit id 'ad873767' to open-iscsi.

(cherry picked from commit 56057900)

Utilize the exit status parameter for virCommandRunRegex in order to
check the return error from the 'iscsiadm --mode session' command.
Without this enabled, if there are no sessions running then virCommandRun
would have displayed an error such as:

    2016-05-13 15:17:15.165+0000: 10920: error : virCommandWait:2553 :
               internal error: Child process (iscsiadm --mode session)
               unexpected exit status 21: iscsiadm: No active sessions.

It is possible that for certain paths (when probe is true) we only care
whether it's running or not to make certain decisions.  Spitting out
the error for those paths is unnecessary.

If we do have a situation where probe = false and there's an error,
then display the error from iscsiadm if it's there.

(cherry picked from commit 8f54e0d6)

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)