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.

The test monitor should be freed separately so we need to remove the
pointer from the @vm object. This fixes a race condition crash in the
test introduced in commit a245abce.

testQemuHotplugCpuDataFree leaked @data always and
testQemuHotplugCpuPrepare leaked @prefix on success

Commit 815d98ac started auto-adding one hub if there are more USB devices
than available USB ports.

This was a strange choice, since there might be even more devices.
Before USB address allocation was implemented in libvirt, QEMU
automatically added a new USB hub if the old one was full.

Adjust the logic to try adding as many hubs as will be needed
to plug in all the specified devices.

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

As bhyve for a long time didn't have a notion of the explicit SATA
controller and created a controller for each drive, the bhyve driver
in libvirt acted in a similar way and didn't care about the SATA
controllers and assigned PCI addresses to drives directly, as
the generated command will look like this anyway:

 2:0,ahci-hd,somedisk.img

This no longer makes sense because:

 1. After commit c07d1c1c it's not possible to assign
    PCI addresses to disks
 2. Bhyve now supports multiple disk drives for a controller,
    so it's going away from 1:1 controller:disk mapping, so
    the controller object starts to make more sense now

So, this patch does the following:

 - Assign PCI address to SATA controllers (previously we didn't do this)
 - Assign disk addresses instead of PCI addresses for disks. Now, when
   building a bhyve command, we take PCI address not from the disk
   itself but from its controller
 - Assign addresses at XML parsing time using the
   assignAddressesCallback. This is done mainly for being able to
   verify address allocation via xml2xml tests
 - Adjust existing bhyvexml2{xml,argv} tests to chase the new
   address allocation

This patch is largely based on work of Fabian Freyer.

Add virBhyveDriverCreateXMLConf, a simple wrapper around
virDomainXMLOptionNew that makes it easier to pass bhyveConnPtr
as a private data for parser. It will be used later for device
address allocation at parsing time.

Update consumers to use it instead of direct calls to
virDomainXMLOptionNew.

As we now have proper callbacks connected for the tests, update
test files accordingly to include the automatically generated
PCI root controller.

The input and output were the same, but the output file did not
correspond to what libvirt would output.

The issue is that if this graphics definition is provided:

  <graphics type='vnc' port='0'/>

it's parsed as:

  <graphics type='vnc' autoport='no'>
    <listen type='address'/>
  </graphics>

but if the resulting XML is parsed again the output is:

  <graphics type='vnc' port='-1' autoport='yes'>
    <listen type='address'/>
  </graphics>

and this should not happen.  The XML have to always remain the same
after it was already parsed by libvirt.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1383039Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Not only we should set the MTU on the host end of the device but
also let qemu know what MTU did we set.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far we allow to set MTU for libvirt networks. However, not all
domain interfaces have to be plugged into a libvirt network and
even if they are, they might want to have a different MTU (e.g.
for testing purposes).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Based on work of Mehdi Abaakouk <sileht@sileht.net>.

When parsing vhost-user interface XML and no ifname is found we
can try to fill it in in post parse callback. The way this works
is we try to make up interface name from given socket path and
then ask openvswitch whether it knows the interface.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When generating a domain XML from native command (i.e. via
the connectDomainXMLFromNative call), we should use
interface type 'bridge' rather than 'ethernet' because we only
support bridges at this point.

As we don't have bridge name explicitly specified on the command line,
just use 'virbr0' as a default.

Separate the headers so that functions only required for testing of the
sheepdog backend are separated into their own file.

The file became a garbage dump for all kinds of utility functions over
time. Move them to a separate file so that the files can become a clean
interface for the storage backends.

While local builds succeed fine, a build worker building in a
chroot environment is encountering the following error with
libvirt 3.0.0 release candidates

[  162s] shunloadtest.o: In function `main':
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:110: undefined reference to `dlopen'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:114: undefined reference to `dlsym'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:133: undefined reference to `dlclose'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:111: undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:115: undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:116: undefined reference to `dlclose'

Fix by appending DLOPEN_LIBS to shunloadtest_LDADD.

fabric_name is one of many fc_host attributes in Linux that is optional
and left to the low-level driver to decide if it is implemented.
The zfcp device driver does not provide a fabric name for an fcp host.

This patch removes the requirement for a fabric name by making it optional.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

Starting from a245abce another set of tests for
qemuhotplugtest has been introduced. This time for vcpu hotplug.
However, the test data (which live in qemuhotplugtestcpus dir)
are not being distributed properly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a positive test and few negative tests.