Up until a while ago, libvirt would automatically add a legacy
PCI controllers combo (dmi-to-pci-bridge + pci-bridge) to any
PCIe machine type (x86_64/q35 and aarch64/virt).

As a result, a number of input and output files in the test
suite ended up containing the legacy PCI controllers, even
though they are not needed or in any way relevant to the
feature being tested.

Get rid of most of the occurrences. Most of the time, this
just means removing the controllers from the input file and
regenerating the output files; in a few instances, some
minor tweaking is performed on the input file, most notably
removing the memory balloon: as memory balloon support was
not the scope of the test being changed, there is no loss
of test coverage from doing so.

Several occurrences of the legacy PCI controllers remain in
the test suite, both because removing their usage would have
required even more tweaking, and because we still want to
have coverage of this perfectly valid combination.

The 'raw' block driver in Qemu is not directly interesting from
libvirt's perspective, but it can be layered above some other block
drivers and this may be interesting for the user.

The patch adds support for the 'raw' block driver. The driver is treated
simply as a pass-through and child driver in JSON is queried to get the
necessary information.
Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>

Add a new storage driver registration function that will force the
backend code to fail if any of the storage backend modules can't be
loaded. This will make sure that they work and are present.

If driver modules are enabled turn storage driver backends into
dynamically loadable objects. This will allow greater modularity for
binary distributions, where heavyweight dependencies as rbd and gluster
can be avoided by selecting only a subset of drivers if the rest is not
necessary.

The storage modules are installed into 'LIBDIR/libvirt/storage-backend/'
and users can override the location by using
'LIBVIRT_STORAGE_BACKEND_DIR' environment variable.

rpm based distros will at this point install all the backends when
libvirt-daemon-driver-storage package is installed.

Test that the vcpu entity selection code works properly

Add APIs that allow to dynamically register driver backends so that the
list of available drivers does not need to be known during compile time.

This will allow us to modularize the storage driver on runtime.

Pass the registration function name to virDriverLoadModule so that we
can later call specific functions if necessary (e.g. for testing
purposes). This gets rid of the rather ugly automatic name generator and
unifies the code to load/initialize the modules.

It's also clear which registration function gets called.

Refactors of the test resulted into the second argument of the 'TEST'
macro to be unused. Drop them.

The XML2XML test should work properly even if the storage backend is
disabled, since it does not use it.

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

QEMU 2.9.0 is not released yet but it's close to its release and
we need this data to implement new features that will be in
that release.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The old data was generated from not released QEMU.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add a test that allows providing the parent fabric_wwn in the input XML
in order to create the vHBA.

This also fixes a mixed setting of the fabric_wwn field from the read
test driver XML strings.

Add a test that allows providing the parent wwnn/wwpn in the input XML
in order to create the vHBA.

Add a test that allows not providing a parent in the input XML, but still
being able to create finding a VPORT capable NPIV HBA.

Add a test that will mimic creation and destruction of a vHBA
by using node device XML. The design will allow for testing the
multiple mechanisms.

The first test uses just <parent> in the node device XML. This is
somewhat similar to the existing objecteventtest, except that this
test will not provide input wwnn/wwpn's (similar to how the process
is described for the the libvirt wiki).

This requires mocking the virRandomGenerateWWN since parsing the
input XML (virNodeDevCapSCSIHostParseXML) requires either a provided
wwnn/wwpn in the XML or the ability to randomly generate the wwnn/wwpn.

Create a virscsihost.c and place the functions there. That removes the
last #ifdef __linux__ from virutil.c.

Take the opporunity to also change the function names and in one case
the parameters slightly

Rather than have them mixed in with the virutil apis, create a separate
virvhba.c module and move the vHBA related calls into there. Soon there
will be more added.

Also modify the names of the functions and some arguments to be more
indicative of what is really happening. Adjust the callers respectively.

While I was changing fchosttest, rather than the non-descriptive names
test1...test6, rename them to match what the test is doing.

Commit id '666bee39' made fabric_name optional; however, if fabric name
was present, then a leak would occur.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Alter "test-scsi-host-vport" to be "scsi_host1" to match the real
environment. This is the vport capable HBA - IOW the NPIV device.
Add more fields to scsi_host1 as well.

Alter the XML being used by the objecttest to create a vHBA in order
to match the scsi_host1 parent name and to use validateable wwnn/wwpn.
This will allow for realistic testing.

Add a new attribute 'rendernode' to <gl> spice element.

Give it to QEMU if qemu supports it (queued for 2.9).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new 'drm' capability for Direct Rendering Manager (DRM) devices,
providing device type information.

Teach the udev backend to populate those devices.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add new <devnode> top-level <device> element, that list the associated
/dev files. Distinguish the main /dev name from symlinks with a 'type'
attribute of value 'dev' or 'symlink'.

Update a test to check XML schema, and actually add it to the test list
since it was missing.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

We want to remove the file created by

    json <<<"$data" >$fname.json

in case it was empty.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Currently disk names do not follow the
(regex) /^[fhv]d[a-z]+[0-9]*$/ completely
and hence one can assign disk names like
vd2 etc. This patch ensures that the
disk names follow the regex mentioned.
This patch also adds a testcase.
Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

To make sure bit 'b' fits into the bitmap, we need to allocate b+1
bits, since we number from 0.

Adjust the bitmap test to set a bit at a multiple of 16.
That way the test fails without this fix, because the VIR_REALLOC
call clears the newly added memory even if the original pointer
has not changed.

Add suppression for memory leak in bash observerd with bash 4.4.011 on
Arch Linux.
Signed-off-by: NTomáš Golembiovský <tgolembi@redhat.com>

This controller only allows up to 15 ports.

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

Due to a logic error, the autofilling of USB port when a bus is
specified:
    <address type='usb' bus='0'/>
does not work for non-hub devices on domain startup.

Fix the logic in qemuDomainAssignUSBPortsIterator to also
assign ports for USB addresses that do not yet have one.

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

Recently e1000 NIC support was added to bhyve; implement that in
the bhyve driver:

 - Add capability check by analyzing output of the 'bhyve -s 0,e1000'
   command
 - Modify bhyveBuildNetArgStr() to support e1000 and also pass
   virConnectPtr so it could call bhyveDriverGetCaps() to check if this
   NIC is supported
 - Modify command parsing code to add support for e1000 and adjust tests
 - Add net-e1000 test

Seeing similar error to commit id '997be5c2' with the inability
to find the libvirt_event_poll_purge_timeout_semaphore symbol
causing a virusbtest failure.

==22187== 77 (56 direct, 21 indirect) bytes in 1 blocks are definitely lost in loss record 23 of 37
==22187==    at 0x4C2BC75: calloc (vg_replace_malloc.c:624)
==22187==    by 0x4E75685: virAlloc (viralloc.c:144)
==22187==    by 0x4F0613A: virUSBDeviceNew (virusb.c:332)
==22187==    by 0x4F05BA2: virUSBDeviceSearch (virusb.c:183)
==22187==    by 0x4F05F95: virUSBDeviceFind (virusb.c:296)
==22187==    by 0x403514: testUSBList (virusbtest.c:209)
==22187==    by 0x403BD8: virTestRun (testutils.c:180)
==22187==    by 0x4039E5: mymain (virusbtest.c:285)
==22187==    by 0x4056BC: virTestMain (testutils.c:992)
==22187==    by 0x403A4A: main (virusbtest.c:293)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We are using couple of functions from there (e.g. virStrdup) and
rely that the binary linking us has the libvirt_utils linked
already. Well, this makes valgrind sad.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

A lot of our tests re-execute themeselves after loading their
mock library. This, however, makes valgrind sad because currently
we do not tell it to trace the process after exec().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch add support for file memory backing on numa topology.

The specified access mode in memoryBacking can be overriden
by specifying token memAccess in numa cell.

This part introduces new xml elements for file based
memorybacking support and their parsing.
(It allows vhost-user to be used without hugepages.)

New xml elements:
<memoryBacking>
  <source type="file|anonymous"/>
  <access mode="shared|private"/>
  <allocation mode="immediate|ondemand"/>
</memoryBacking>

Example:

  <network>
     ...
     <mtu size='9000'/>
     ...

If mtu is unset, it's assumed that we want the default for whatever is
the underlying transport (usually this is 1500).

This setting isn't yet wired in, so it will have no effect.

This partially resolves: https://bugzilla.redhat.com/1224348

virNetDevTapCreateInBridgePort() has always set the new tap device to
the current MTU of the bridge it's being attached to. There is one
case where we will want to set the new tap device to a different
(usually larger) MTU - if that's done with the very first device added
to the bridge, the bridge's MTU will be set to the device's MTU. This
patch allows for that possibility by adding "int mtu" to the arg list
for virNetDevTapCreateInBridgePort(), but all callers are sending -1,
so it doesn't yet have any effect.

Since the requested MTU isn't necessarily what is used in the end (for
example, if there is no MTU requested, the tap device will be set to
the current MTU of the bridge), and the hypervisor may want to know
the actual MTU used, we also return the actual MTU to the caller (if
actualMTU is non-NULL).

In order for memory locking to work, the hard limit on memory
locking (and usage) has to be set appropriately by the user.

The documentation mentions the requirement already: with this
patch, it's going to be enforced by runtime checks as well,
by forbidding a non-compliant guest from being defined as well
as edited and started.

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

Like it usually happens, I fixed one thing and broke another:
in 803966c7 address allocation was fixed for SATA disks, but
broke that for virtio disks, because it dropped disk address
assignment completely. It's not needed for SATA disks anymore,
but still needed for the virtio ones.

Bring that back and add a couple of tests to make sure it won't
happen again.