Ever since commit ace4aecd, running 'make check' on RHEL 6 produces:

./test-lib.sh: line 21: realpath: command not found

for every shell script test, because 'realpath' was not part of
coreutils back then.

* tests/test-lib.sh (_scriptdir): Compute with only portable shell.
Signed-off-by: NEric Blake <eblake@redhat.com>

The name is confusing, and there are just two uses: one is a test case,
and the other will be removed as part of an upcoming refactoring of
the hostdev code.

The current code was a little bit odd.  At first we've removed all
possible implicit input devices from domain definition to add them later
back if there was any graphics device defined while parsing XML
description.  That's not all, while formating domain definition to XML
description we at first ignore any input devices with bus different to
USB and VIRTIO and few lines later we add implicit input devices to XML.

This seems to me as a lot of code for nothing.  This patch may look
to be more complicated than original approach, but this is a preferred
way to modify/add driver specific stuff only in those drivers and not
deal with them in common parsing/formating functions.

The update is to add those implicit input devices into config XML to
follow the real HW configuration visible by guest OS.

There was also inconsistence between our behavior and QEMU's in the way,
that in QEMU there is no way how to disable those implicit input devices
for x86 architecture and they are available always, even without graphics
device.  This applies also to XEN hypervisor.  VZ driver already does its
part by putting correct implicit devices into live XML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Those tests are in qemuargv2xmltest and it makes sense to include them
also in qemuxml2xmltest and qemuxml2argvtest.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This will enable regenerate functionality for those tests to make
developer lives easier while updating tests.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Report
error: invalid argument: requested vcpu '100' is not present in the domain
instead of
error: invalid argument: requested vcpu is higher than allocated vcpus

A future patch will refactor the storage of the pinning information in a
way where the ordering will be lost. Order them numerically to avoid
changing the tests later.

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

We are missing this value for cdrom-image device. It seems like
there's no added value to extend this to other types of disk
devices [1].

1: https://www.redhat.com/archives/libvir-list/2016-January/msg01038.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Make bhyveload respect boot order as specified by os.boot section of the
domain XML or by "boot order" for specific devices. As bhyve does not
support a real boot order specification right now, it's just about
choosing a single device to boot from.

... and consolidate the cmdline/extra/root parsing to facilitate doing
so.

The logic is the same as xl's parse_cmdline from the current xen.git master
branch (e6f0e099d2c17de47fd86e817b1998db903cab61).

On the formatting side switch to producing cmdline= instead of extra=.

Update a few tests and add serveral more.
  - test-cmdline is added to test the exclusive use of cmdline.
  - test-fullvirt-direct-kernel-boot.cfg is updated due to the switch
    on the formatting side and now tests the exclusive use of cmdline=.
  - Tests are added for both paravirt and fullvirt where the .cfg uses
    extra= and (paravirt only) root=. These are format (xl->xml) only
    since the inverse will generate cmdline= hence is not a round trip
    (which was already true if using root=, which used to generate
    extra= on the way back).
  - Tests are added for both paravirt and fullvirt where the .cfg
    declares cmdline= as well as bogus extra= and (paravirt only) root=
    entries which should be ignored. Again these are format only tests
    since the inverse won't include the bogus lines.

The last two bullets here required splitting the DO_TEST macro into
two halves, as is done in the xmconfigtest.c case.

In order to introduce a use of VIR_WARN for logging I had to add
virerror.h and VIR_LOG_INIT.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>

Add a new storage pool source device attribute 'part_separator=[yes|no]'
in order to allow a 'disk' storage pool using a device mapper multipath
device to not add the "p" partition separator to the generated device
name when libvirt_parthelper is run.

This will allow libvirt to find device mapper multipath devices which were
configured in /etc/multipath.conf to use 'user_friendly_names' or custom
'alias' names for the LUN.

In the commit aea47e48 we have fixed a single pointer within
driver structure. Since all callers pass statically allocated
driver on stack other pointers within driver may contain random
values too. Before touching it lets overwrite it with zeroes and
thus fix all dangling pointers.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

- Don't double check for expectName
- actual is always non-NULL by this point, so don't check it either

Autodeflate can be enabled/disabled for memballon device
of model 'virtio'.

xml:
<devices>
  <memballoon model='virtio' autodeflate='on'/>
</devices>

qemu:
qemu -device virtio-balloon-pci,...,deflate-on-oom=on

Autodeflate cannot be enabled/disabled for running domain.

Add appropriate capability check and new virQEMUCaps flag for the new
virtio balloon feature. QEMU commit with the complete feature description:
http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc14d841b80

Use virDomainDefAddUSBController() to add an EHCI1+UHCI1+UHCI2+UHCI3
controller set to newly defined Q35 domains that don't have any USB
controllers defined.

The real Q35 machine puts the first USB controller set (EHCI+(UHCIx4))
on bus 0 slot 0x1D, and the 2nd USB controller set on bus 0 slot 0x1A,
so let's attempt to make the virtual machine match that for
controllers with auto-assigned addresses when possible.

Three test cases were added to assure that the proper addresses are
assigned - one with a single set of unaddressed USB controllers, one
with 3 (to grab both preferred slots plus one more), and one with the
order of the controller definitions reordered, to assure that the
auto-assignment isn't mixed up by order.

This capability tells if qemu is capable of vserport_change
events.
Signed-off-by: NMichal Privoznik <mprivozn@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 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.

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.

The structure actually contains migration statistics rather than just
the status as the name suggests. Renaming it as
qemuMonitorMigrationStats removes the confusion.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Those parameters should be in opposite order.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Let's use the new virTestDifferenceFull function that will regenerate
the expected output and fail the test to let developer know that there
something was updated.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This patch enable regeneration of expected output file for
virTestDifferenceFull.  It also introduces new
virTestDifferenceFullNoRegenerate function for special cases, where we
don't want to regenerate output.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

When this flag is specified, some of the expected output files will be
regenerated with the actual output data.  Use helper function like for
other flags.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If user defines a virtio channel with UNIX socket backend and doesn't
care about the path for the socket (e.g. qemu-agent channel), we still
generate it into the persistent XML.  Moreover when then user renames
the domain, due to its persistent socket path saved into the per-domain
directory, it will not start.  So let's forget about old generated paths
and also stop putting them into the persistent definition.

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

Just recently, qemu forbade specifying format for sourceless
disks (qemu commit 39c4ae941ed992a3bb5). It kind of makes sense.
If there's no file to open, why specify its format. Anyway, I
have a domain like this:

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

and obviously I am unable to start it. Therefore, a fix on our
side is needed too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>