Move all the logic to include/Makefile.am, simplify it with a wildcard,
then kill include/libvirt/Makefile.am

In wireshark commit ceb8d954 (v1.99.2) they have changed the
signature of a function that determines how long a libvirt packet
is. Now it accepts a void pointer for passing data into the
function. Well, this is nice, but we don't need it right now.
Anyway, we have to change our code.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the upcoming patch we will need yet another #ifdef code block
depending on wireshark version. Instead of defining
WIRESHARK_COMPAT2 or something lets just compare the version
right at the place so that we can clearly see what version broke
API.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In wireshak commit 22149c55 (v.1.11.3) the API was renamed.
Follow the change in our code too. Since the wireshark change was
made in the very same version that we require at least we are
good to go.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In wireshark, they have introduced their own memory allocator
wmem. This means that we need to adapt our code to that change
too. Notably 0ad15f88ccf434e8210ca is the wireshark commit you
want to look at. It's the one where they dropped the old API. The
new allocator has been introduced in 84cc3daa (v1.10.0), however,
was not exposed until 5c05c9e0 (v1.10.0). Since we already are
requiring 1.11.3 or higher no other change is needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the wireshark commit e2735ecfdd7a96c they dropped
proto_tree_add_text in favor of proto_tree_add_item. Adapt to
this change.

Moreover, the proto_tree_add_item API is around for ages and we
are already using it anyway. Therefore we don't need to change
required version of wireshark.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This capability tells if qemu is capable of vserport_change
events.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While this is no functional change, whole channel definition is
going to be needed very soon. Moreover, while touching this obey
const correctness rule in qemuAgentOpen() - so far it was passed
regular pointer to channel config even though the function is
expected to not change pointee at all. Pass const pointer
instead.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In qemu driver we listen to virtio channel events like an agent
connected to or disconnected from the guest part of socket.
However, with a little exception - when we find out that the
socket in question is the guest agent one, we connect or
disconnect guest agent which is done prior setting new state in
internal structure. Due to a bug in our code it may happen that
we got the event but failed to set it in internal structure
representing the channel.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Commit b22344f3 mistakenly reordered
Default-* lines.  Thanks to that I noticed that we are very inconsistent
with our init scripts, so I took the liberty of synchronizing them,
updating them and making them all look shiny and new.  So apart from
fixing the LSB requirements, I also fixed the ordering, specified
runlevels and fix the link to the reference specification.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We have a policy that if API may end up talking to a guest agent
it should require RW connection. We don't obey the rule in
virDomainGetTime().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This API does not change domain state. However, we have a policy
that an API talking to a guest agent requires RW access. But that
happens only if source == VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The event, net-event and qemu-monitor-event virsh commands all
support the --timestamp option now, but such option was not
referenced in the man page.

Implement a --timestamp option for 'virsh net-event', similar to the
one for 'virsh event'.

When the option is used, the human-readable timestamp will be printed
before the message.

Implement a --timestamp option for 'virsh qemu-monitor-event', similar
to the one for 'virsh event'.

When the option is used, the human-readable timestamp will be printed
before the message, and the timing information provided by QEMU will
not be displayed.

Earlier commit 71408079 forgot to deal
properly with status XMLs where we want the libvirt-internal paths to be
kept in place and not cleared, otherwise we could end up copying a NULL
string and segfaulting th daemon.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

This way both Domain and Device PostParse functions can act based on the
flags.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If the q35 specific disable s3/s4 setting isn't supported, fallback to
specifying the PIIX setting, which is the previous behavior. It doesn't
have any effect, but qemu will just warn about it rather than error:

  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s3=1 not used
  qemu-system-x86_64: Warning: global PIIX4_PM.disable_s4=1 not used

Since it doesn't error, I don't think we should either, since there
may be configs in the wild that already have q35 + disable_s3/4 (via
virt-manager)

Update test data to match

These settings are specific to PIIX, so clarify it

The chipset is called PIIX; the functions are misnamed

Using one Makefile per example subdirectory essentially serializes 'make'
calls. Convert to one example/Makefile that builds and distributes
all the subdir files. This reduces example/ rebuild time from about 5.8
seconds to 1.5 seconds on my machine.

One slight difference is that we no longer ship Makefile.am with the
examples in the rpm. This was virtually useless anyways since the Makefile
was very specific to libvirt infrastructure, so wasn't generically
reusable anyways.

Tested with 'make distcheck' and 'make rpm'

The period makes it more difficult to copy/paste the errant filename
for manual fixup

No only coverity warns about this, but it kind of makes sense
too. We have a test whether host supports IOMMU. Some platforms
don't have it, I know. But in that case we should print a message
that it's unknown whether platform has it or not.

Before:
  (no output)

After:
  QEMU: Checking for device assignment IOMMU support                         : WARN (Unknown if this platform has IOMMU support)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function may be called with @dconnuri == NULL, e.g. from
virDomainMigrateToURI3() if the flags are missing
VIR_MIGRATE_PEER2PEER flag. Moreover, all later functions called
from here do wrap it into NULLSTR() so why not do the same here?
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The condition was checking for UHCI (and OHCI for ppc64) availability so
that it can specify the proper device instead of legacy usb.  However,
for ppc64, we don't need to check both OHCI and UHCI, but only OHCI as
that is the legacy default.  The condition is so big that it was just a
matter of time when someone will make a mistake there, so let's use more
lines so that it is visible what the condition checks for.

This fixes usage of -device instead of -usb for ppc64 that supports
pci-usb-ohci and does not support piix3-usb-uhci.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1297020Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

For some reason we are not setting the driver with memset() to zeros.
But since commit 74abc3de
driver->securityManager is being accessed and qemuagenttest started
crashing due to that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Future changes will make some of these tests dependent on specific
QEMUCaps flags, so wire up the basic handling. Flags will be added
in future patches.

For testing hypervisor independent XML handling. Right now it's just
populated with an example test case.

For the standard active/inactive XML testing, if we leave the file loading
up to the generic XML2XML infrastructure, we get the benefit of
VIR_TEST_REGENERATE_OUTPUT, at the price of a few more disk reads. Seems
worth it.

This creates a shared function in testutils.c that consolidates all
the slightly different implementations.

Previously it failed like:

$ ./tests/domainschematest
./tests/domainschematest: line 4: ./test-lib.sh: No such file or directory

Since test files are formatted predictably nowadays, we can make
VIR_TEST_REGENERATE_OUTPUT handle most cases for us with a simple
replacement. test-wrap-argv.pl is still canon, but this bit makes
it easier to confirm test output changes during active development.

The libxl_device_nic structure supports specifying an outgoing rate
limit based on a time interval and bytes allowed per interval. In xl
config a rate limit is specified as "<RATE>/s@<INTERVAL>". INTERVAL
is optional and defaults to 50ms.

libvirt expresses outgoing limits by average (required), peak, burst,
and floor attributes in units of KB/s. This patch supports the outgoing
bandwidth limit by converting the average KB/s to bytes per interval
based on the same default interval (50ms) used by xl.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Both xm and xl config have long supported specifying vif rate
limiting, e.g.

vif = [ 'mac=00:16:3E:74:3d:76,bridge=br0,rate=10MB/s' ]

Add support for mapping rate to and from <bandwidth> in the xenconfig
parser and formatter. rate is mapped to the required 'average' attribute
of the <outbound> element, e.g.

  <interface type='bridge'>
    ...
    <bandwidth>
      <outbound average='10240'/>
    </bandwidth>
  </interface>

Also add a unit test to check the conversion logic.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

The xen sexpr config format has long supported specifying vif rate
limiting, e.g.

  (device
    (vif
      (mac '00:16:3e:1b:b1:47')
      (rate '10240KB/s')
      ...
    )
  )

Add support for mapping rate to and from <bandwidth> in the xenconfig
sexpr parser and formatter. rate is mapped to the required 'average'
attribute of the <outbound> element, e.g.

  <interface type='bridge'>
    ...
    <bandwidth>
      <outbound average='10240'/>
    </bandwidth>
  </interface>

Also add unit tests to check the conversion logic.

This patch benefits both the old xen driver and the libxl driver.
Both drivers gain support for vif bandwidth when converting to/from
domXML and xen-sxpr. In addition, the old xen driver will now be
able to handle vif 'rate' setting when communicating with xend.

We weren't checking for failure of qemuCaps lookup

Somehow I managed to backspace over the newline between the closing
brace and goto cleanup; in commit 36e244f3.