The struct contains a single boolean field, 'supported':
the meaning of this field is too generic to be limited to
devices only, and in fact it's already being used for
other things like loaders and OSs.

Instead of trying to come up with a more generic name just
get rid of the struct altogether.

We already reject a VM with min_guarantee early in the VM startup
in qemuProcessStartValidate

The common idiom in the driver API implementations is roughly:

- ACL check
- BeginJob (if needed)
- AgentAvailable (if needed)
- !IsActive

A few calls had an extra !IsActive before BeginJob, which doesn't
seem to serve much use. Drop them

It already labels abritrary paths, so it's just the naming that was
wrong.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Migration API allows to specify a destination domain configuration.
Offline domain has only inactive XML and it is replaced by configuration
specified using VIR_MIGRATE_PARAM_DEST_XML param. In case of live
migration VIR_MIGRATE_PARAM_DEST_XML param is applied for active XML.

This commit introduces the new VIR_MIGRATE_PARAM_PERSIST_XML param
that can be used within live migration to replace persistent/inactive
configuration.

Required for: https://bugzilla.redhat.com/show_bug.cgi?id=835300

This changes allow to use qemuMigrationCookieAddPersistent with
an XML definition that isn't assigned to any domain.

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.

Commit id '0da965c5' removed the 11th parameter, but neglected to
remove the ATTRIBUTE_NONNULL for it and adjust the 17th and 18th.

When creating the master key, we used mode 0600 (which we should) but
because we were creating it as root, the file is not readable by any
qemu running as non-root.  Fortunately, it's just a matter of labelling
the file.  We are generating the file path few times already, so let's
label it in the same function that has access to the path already.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In a few places in libvirt we busy-wait for events, for example qemu
creating a monitor socket.  This is problematic because:

 - We need to choose a sufficiently small polling period so that
   libvirt doesn't add unnecessary delays.

 - We need to choose a sufficiently large polling period so that
   the effect of busy-waiting doesn't affect the system.

The solution to this conflict is to use an exponential backoff.

This patch adds two functions to hide the details, and modifies a few
places where we currently busy-wait.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Rather than trying some magic calculations on our side query the monitor
for the current size of the memory balloon both on hotplug and
hotunplug.

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

No need to store failure and re-check right away.

Now that there is just one format of the memory balloon command line
used the code can be merged into a single function.

Additionally with some tweaks to the control flow the code is easier to
read.

The change that made qemu not add the memballoon by default happened
prior to 0.12.0. Additionaly the comment was misleading due to the code
that was added below. Since we always need to add a balloon on the
commandline drop the comment.

The flag is now unused and all qemus supported by libvirt already
support it.

The only caller of this code is:

    for (i = 0; i < dom->def->ngraphics; i++) {
       if (dom->def->graphics[i]->type == VIR_DOMAIN_GRAPHICS_TYPE_SPICE) {
           if (!(mig->graphics =
                 qemuMigrationCookieGraphicsAlloc(driver, dom->def->graphics[i])))
               return -1;
           mig->flags |= QEMU_MIGRATION_COOKIE_GRAPHICS;
           break;
       }
    }

So this is never triggered for VNC, and in fact VNC has no support for
seamless migration anyways so that seems correct. Drop the dead VNC
handling.

This is backed by the qemu device pxb-pcie, which will be available in
qemu 2.6.0.

As with pci-expander-bus (which uses qemu's pxb device), the busNr
attribute and <node> subelement of <target> are used to set the bus_nr
and numa_node options.

During post-parse we validate that the domain's machinetype is
q35-based (since the device shows up for 440fx-based machinetypes, but
is unusable), as well as checking that <node> specifies a node that is
actually configured on the guest.

This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).

Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).

    The pxb device is a PCIe expander bus that can be added to any
    Q35-based machinetype. A single PCIe port (*not* hotpluggable) is
    provided; if more than one device is desired, or if hotplug
    support is needed, either a pcie-root-port, or some combination of
    pcie-switch-upstream-port and pcie-swith-downstream-ports must be
    added to it. It can have a NUMA node number associated with it, as
    well as a bus number.

This is backed by the qemu device "pxb".

The pxb device always includes a pci-bridge that is at the bus number
of the pxb + 1.

busNr and <node> from the <target> subelement are used to set the
bus_nr and numa_node options for pxb.

During post-parse we validate that the domain's machinetype is
440fx-based (since the pxb device only works on 440fx-based machines),
and <node> also gets a sanity check to assure that the NUMA node
specified for the pxb (if any - it's optional) actually exists on the
guest.

This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.

The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).

Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.

The pxb device is a PCI expander bus that can be added to any
440fx-based machinetype. The PCI bus that is created has 32 standard
PCI slots (hotpluggable). It can have a NUMA node number associated
with it, as well as a bus number.

Since every PCI controller model has to have a default model name set,
put it in a separate function to clean up qemuDomainAssignPCIAddresses
a bit.

There are two places in qemu_domain_address.c where we have a switch
statement to convert PCI controller models
(VIR_DOMAIN_CONTROLLER_MODEL_PCI*) into the connection type flag that
is matched when looking for an upstream connection for that model of
controller (VIR_PCI_CONNECT_TYPE_*). This patch makes a utility
function in conf/domain_addr.c to do that, so that when a new PCI
controller is added, we only need to add the new model-->connect-type
in a single place.

The flags used to determine which devices could be plugged into which
controllers were quite confusing, as they tried to create classes of
connections, then put particular devices into possibly multiple
classes, while sometimes setting multiple flags for the controllers
themselves. The attempt to have a single flag indicate, e.g. that a
root-port or a switch-downstream-port could connect was not only
confusing, it was leading to a situation where it would be impossible
to specify exactly the right combinations for a new controller.

The solution is for the VIR_PCI_CONNECT_TYPE_* flags to have a 1:1
correspondence with each type of PCI controller, plus a flag for a PCI
endpoint device and another for a PCIe endpoint device (the only
exception to this is that pci-bridge and pcie-expander-bus controllers
have their upstream connection classified as
VIR_PCI_CONNECT_TYPE_PCI_DEVICE since they can be plugged into
*exactly* the same ports as any endpoint device).  Each device then
has a single flag for connect type (plus the HOTPLUG flag if that
device can e hotplugged), and each controller sets the CONNECT bits
for all controllers that can be plugged into it, as well as for either
type of endpoint device that can be plugged in (and the HOTPLUG flag
if it can accept hotplugged devices).

With this change, it is *slightly* easier to understand the matching
of connections (as long as you remember that the flag for a
device/upstream-facing connection of a controller is the same as that
device's type, while the flags for a controller's downstream
connections is the OR of all device types that can be plugged into
that controller). More importantly, it will be possible to correctly
specify what can be plugged into a pcie-switch-expander-bus, when
support for it is added.

The watchdog cli refactoring in 4666b762 dropped the temporary variable
we use to convert to action=dump to action=pause for the qemu cli, and
stored the converted value in the domain structure. Our other watchdog
handling code then treated it as though the user requested action=pause,
which broke action=dump handling.

Revive the temporary variable to fix things.

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NShaoHe Feng <shaohe.feng@intel.com>
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

I tried compiling libvirt with older gcc and probably because I used
different configure options I got some shadowed declarations.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

GCC in RHEL-6 complains about listen:

../../src/conf/domain_conf.c:23718: error: declaration of 'listen' shadows a global declaration [-Wshadow]
/usr/include/sys/socket.h:204: error: shadowed declaration is here [-Wshadow]

This renames all the listen to gListen.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This is just a wrapper for virCommand that takes two strings
and runs them.

Move it to virnetdev.c for easier mocking.

Since qemu is now able to notify us that the guest rejected the memory
unplug operation we can relay this to the user and make the API fail
right away.

Additionally document the possible values from the ACPI docs for future
reference.

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

The event is emitted on ACPI OSPM Status Indication events.

ACPI standard documentation describes the method as:

This object is an optional control method that is invoked by OSPM to
indicate processing status to the platform. During device ejection,
device hot add, or other event processing, OSPM may need to perform
specific handshaking with the platform. OSPM may also need to indicate
to the platform its inability to complete a requested operation; for
example, when a user presses an ejection button for a device that is
currently in use or is otherwise currently incapable of being ejected.
In this case, the processing of the ACPI Eject Request notification by
OSPM fails. OSPM may indicate this failure to the platform through the
invocation of the _OST control method. As a result of the status
notification indicating ejection failure, the platform may take certain
action including reissuing the notification or perhaps turning on an
appropriate indicator light to signal the failure to the user.

Similarly to the DEVICE_DELETED event we will be able to tell when
unplug of certain device types will be rejected by the guest OS. Wire up
the device deletion signalling code to allow handling this.

No need to keep two separate conditions. A slight juggling of return
values is needed to accomodate virDomainObjWaitUntil.

Neither of the callers cares whether the DEVICE_DELETED event isn't
supported or the event was received. Simplify the code and callers by
unifying the two values and changing the return value constants so that
a temporary variable can be omitted.