This text was in the commit log for the patch that added the event
handler for NIC_RX_FILTER_CHANGED, and John Ferlan expressed a desire
that the information not be "lost", so I've put it into a file in the
qemu directory, hoping that it might catch the attention of future
writers of handlers for qemu events.

This function can be called at any time to get the current status of a
guest's network device rx-filter. In particular it is useful to call
after libvirt recieves a NIC_RX_FILTER_CHANGED event - this event only
tells you that something has changed in the rx-filter, the details are
retrieved with the query-rx-filter monitor command (only available in
the json monitor). The command sent to the qemu monitor looks like this:

  {"execute":"query-rx-filter", "arguments": {"name":"net2"} }'

and the results will look something like this:

{
    "return": [
        {
            "promiscuous": false,
            "name": "net2",
            "main-mac": "52:54:00:98:2d:e3",
            "unicast": "normal",
            "vlan": "normal",
            "vlan-table": [
                42,
                0
            ],
            "unicast-table": [

            ],
            "multicast": "normal",
            "multicast-overflow": false,
            "unicast-overflow": false,
            "multicast-table": [
                "33:33:ff:98:2d:e3",
                "01:80:c2:00:00:21",
                "01:00:5e:00:00:fb",
                "33:33:ff:98:2d:e2",
                "01:00:5e:00:00:01",
                "33:33:00:00:00:01"
            ],
            "broadcast-allowed": false
        }
    ],
    "id": "libvirt-14"
}

This is all parsed from JSON into a virNetDevRxFilter object for
easier consumption. (unicast-table is usually empty, but is also an
array of mac addresses similar to multicast-table).

(NB: LIBNL_CFLAGS was added to tests/Makefile.am because virnetdev.h
now includes util/virnetlink.h, which includes netlink/msg.h when
appropriate. Without LIBNL_CFLAGS, gcc can't find that file (if
libnl/netlink isn't available, LIBNL_CFLAGS will be empty and
virnetlink.h won't try to include netlink/msg.h anyway).)

Check for !dev->info.alias was done after a VIR_DEBUG() statement
that already tried to print - just flip sequence

Prior patch removed the need for the virConnectPtr in the unplug
detach host path which caused ripple effect to remove in multiple
callers.  The previous patch just left things as ATTRIBUTE_UNUSED -
this patch will remove the variable.

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

Introduced by commit id '8f76ad99' the logic to detach a scsi_host
device (SCSI or iSCSI) fails when attempting to remove the 'drive'
because as I found in my investigation - the DelDevice takes care of
that for us.

The investigation turned up commits to adjust the logic for the
qemuMonitorDelDevice and qemuMonitorDriveDel processing for interfaces
(commit id '81f76598'), disk bus=VIRTIO,SCSI,USB (commit id '0635785b'),
and chr devices (commit id '55b21f9b'), but nothing with the host devices.

This commit uses the model for the previous set of changes and applies
it to the hostdev path. The call to qemuDomainDetachHostSCSIDevice will
return to qemuDomainDetachThisHostDevice handling either the audit of
the failure or the wait for the removal and then call into
qemuDomainRemoveHostDevice for the event, removal from the domain hostdev
list, and audit of the removal similar to other paths.

NOTE: For now the 'conn' param to +qemuDomainDetachHostSCSIDevice is left
as ATTRIBUTE_UNUSED.  Removing requires a cascade of other changes to be
left for a future patch.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This patch implements support for the ivshmem device in QEMU.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Ivshmem is supported by QEMU since 0.13 release.
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This patch adds parsing/formatting code as well as documentation for
shared memory devices.  This will currently be only accessible in QEMU
using it's ivshmem device, but is designed as generic as possible to
allow future expansion for other hypervisors.

In the devices section in the domain XML users may specify:

- For shmem device using a server:

 <shmem name='shmem0'>
   <server path='/tmp/socket-ivshmem0'/>
   <size unit='M'>32</size>
   <msi vectors='32' ioeventfd='on'/>
 </shmem>

- For ivshmem device not using an ivshmem server:

 <shmem name='shmem1'>
   <size unit='M'>32</size>
 </shmem>

Most of the configuration is made optional so it also allows
specifications like:

 <shmem name='shmem1/>
 <shmem name='shmem2'>
   <server/>
 </shmem>
Signed-off-by: NMaxime Leroy <maxime.leroy@6wind.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Aeons ago (commit 34dcbbb4, v0.8.2), we added a new libvirt event
(VIR_DOMAIN_EVENT_ID_IO_ERROR_REASON) in order to tell the user WHY
the guest halted.  This is because at least VDSM wants to react
differently to ENOSPC events (resize the lvm partition to be larger,
and resume the guest as if nothing had happened) from all other events
(I/O is hosed, throw up our hands and flag things as broken).  At the
time this was done, downstream RHEL qemu added a vendor extension
'__com.redhat_reason', which would be exactly one of these strings:
"enospc", "eperm", "eio", and "eother".  In our stupidity, we exposed
those exact strings to clients, rather than an enum, and we also
return "" if we did not have access to a reason (which was the case
for upstream qemu).

Fast forward to now: upstream qemu commit c7c2ff0c (will be qemu 2.2)
FINALLY adds a 'nospace' boolean, after discussion with multiple
projects determined that VDSM really doesn't care about distinction
between any other error types.  So this patch converts 'nospace' into
the string "enospc" for compatibility with RHEL clients that were
already used to the downstream extension, while leaving the reason
blank for all other cases (no change from the status quo).

See also https://bugzilla.redhat.com/show_bug.cgi?id=1119784

* src/qemu/qemu_monitor_json.c (qewmuMonitorJSONHandleIOError):
Parse reason field from modern qemu.
* include/libvirt/libvirt.h.in
(virConnectDomainEventIOErrorReasonCallback): Document it.
Signed-off-by: NEric Blake <eblake@redhat.com>

Right now when building the qemu command line, we try to do various
unconditional validations of the guest CPU against the host CPU. However
this checks are overly applied. The only time we should use the checks
are:

- The user requests host-model/host-passthrough, or

- When KVM is requsted. CPU features requested in TCG mode are always
  emulated by qemu and are independent of the host CPU, so no host CPU
  checks should be performed.

Right now if trying to specify a CPU for arm on an x86 host, it attempts
to do non-sensical validation and falls over.

Switch all the test cases that were intending to test CPU validation to
use KVM, so they continue to test the intended code.

Amend some aarch64 XML tests with a CPU model, to ensure things work
correctly.

Move the CPU mode/model handling to its own function. This is just
code movement and re-indentation.

check domain's status before call virQEMUCapsGet to report a accurate
error when domain is shut off

Resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1147847Signed-off-by: NShanzhi Yu <shyu@redhat.com>

Up until now, we set memballoon period in monitor successfully, however
we did not update domain definition structure, thus dumpxml was omitting
period attribute in memballoon element

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

When trying to update bandwidth limits on a running domain, limits get
updated in our internal structures, however XML parser reads
bandwidth limits from network 'actual' definition. Committing this patch
it is now available to update bandwidth 'actual' definition as well,
thus updating domain runtime XML.

If we don't properly clean up all processes in the
machine-<vmname>.scope systemd won't remove the cgroup and subsequent vm
starts fail with

  'CreateMachine: File exists'

Additional processes can e.g. be added via

  echo $PID > /sys/fs/cgroup/systemd/machine.slice/machine-${VMNAME}.scope/tasks

but there are other cases like

  http://bugs.debian.org/761521

Invoke TerminateMachine to be on the safe side since systemd tracks the
cgroup anyway. This is a noop if all processes have terminated already.

and tweak the code to avoid using it.

FreeBSD's compiler complains that we shadow the symbol. Sigh.

s/devname/dev_name/

Otherwise we'd report a different error.

Reported by John Ferlan's coverity run.

Management software wants to be able to allocate disk space on demand.
To support this they need keep track of the space occupation of the
block device.  This information is reported by qemu as part of block
stats.

This patch extend the block information in the bulk stats with the
allocation information.

To keep the same behaviour a helper is extracted from
qemuMonitorJSONGetBlockExtent in order to get per-device allocation
information.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

While our code gathers block stats via "query-blockstats" some
information need to be gathered via "query-block". Add a helper function
that will update the blockstats structure if requested.

This removes the artificial and unnecessary restriction that
virDomainSetMaxDowntime() only be called while a migration is in
progress.

https://bugzilla.redhat.com/show_bug.cgi?id=1146618Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

FreeBSD's compiler complains that we shadow the symbol. Sigh.

s/devname/dev_name/

The current block stats code matched up the disk name with the actual
stats by the order in the data returned from qemu. This unfortunately
isn't right as qemu may return the disks in any order. Fix this by
returning a hash of stats and index them by the disk alias.

Commit fba6bc47 introduced the non-migratable invtsc feature,
breaking save/migration with host-model and host-passthrough.

On hosts with this feature present it was automatically included
in the CPU definition, regardless of QEMU support.

Commit de0aeafe stopped including it by default for host-model,
but failed to fix host-passthrough.

This commit ignores checking of CPU features with host-passthrough,
since we don't pass them to QEMU (only -cpu host is passed),
allowing domains using host-passthrough that were saved with
the broken version of libvirtd to be restored.

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

Introduced by commit 0dce260c.

qemuDomainEventQueue was called with qemuDomainObjPrivatePtr instead
of virQEMUDriverPtr.

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

Prompted by

   http://bugs.debian.org/761131

Fix the typo in VIR_DOMAIN_TUNABLE_CPU_EMULATORIN
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

For the new VIR_DOMAIN_EVENT_ID_TUNABLE event we have a bunch of
constants added

   VIR_DOMAIN_EVENT_CPUTUNE_<blah>
   VIR_DOMAIN_EVENT_BLKDEVIOTUNE_<blah>

This naming convention is bad for two reasons

  - There is no common prefix unique for the events to both
    relate them, and distinguish them from other event
    constants

  - The values associated with the constants were chosen
    to match the names used with virConnectGetAllDomainStats
    so having EVENT in the constant name is not applicable in
    that respect

This patch proposes renaming the constants to

    VIR_DOMAIN_TUNABLE_CPU_<blah>
    VIR_DOMAIN_TUNABLE_BLKDEV_<blah>

ie, given them a common VIR_DOMAIN_TUNABLE prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

On a domain startup, the variable store path is generated if needed.
The path is intended to be generated only once. However, the updated
domain definition is not saved into config dir rather than state XML
only. So later, whenever the domain is destroyed and the daemon is
restarted, the generated path is forgotten and the file may be left
behind on virDomainUndefine() call.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Fix comments about the version in which '.nodeAllocPages' are added.
Signed-off-by: NTomoki Sekiyama <tomoki.sekiyama@hds.com>

Since 363e9a68 we track backing chain metadata when creating snapshots
the right way even for the inactive configuration. As we did not yet
update other code paths that modify the backing chain (blockpull) the
newDef backing chain gets out of sync.

After stopping of a VM the new definition gets copied to the next start
one. The new VM then has incorrect backing chain info. This patch
switches the backing chain detector to always purge the existing backing
chain and forces re-detection to avoid this issue until we'll have full
backing chain tracking support.

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

Use the universal tunable event to report changes to user. All
blkdeviotune values are prefixed with "blkdeviotune".
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When you updated some blkdeviotune values for running domain the values
were stored only internally, but not saved into the live XML so they
won't survive restarting the libvirtd.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

And add stubs to other drivers like: lxc, qemu, uml and vbox.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Format the segment offloading options specified by
<driver>
  <host .../>
  <guest .../>
</driver>
on virtio-net command line.

Request erroring out from the backing chain traveller and drop qemu's
internal backing chain integrity tester.

The backing chain traveller reports errors by itself with possibly more
detail than qemuDiskChainCheckBroken ever could.

We also need to make sure that we reconnect to existing qemu instances
even at the cost of losing the backing chain info (this really should be
stored in the XML rather than reloaded from disk, but that needs some
work).

Reuse virStorageSourceIsEmpty and rename "force" argument to
"force_probe".

Add a new parameter to virStorageFileGetMetadata that will break the
backing chain detection process and report useful error message rather
than having to use virStorageFileChainGetBroken.

This patch just introduces the option, usage will be provided
separately.

Now we have universal tunable event so we can use it for reporting
changes to user. The cputune values will be prefixed with "cputune" to
distinguish it from other tunable events.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>