Since introduction of the DAC security driver we've documented that
seclabels with a leading + can be used with numerical uid. This would
not work though with the rest of libvirt if the uid was not actually
used in the system as we'd fail when trying to get a list of
supplementary groups for the given uid. Since a uid without entry in
/etc/passwd (or other user database) will not have any supplementary
groups we can treat the failure to obtain them as such.

This patch modifies virGetGroupList to not report the error for missing
users and makes it return an empty list or just the group specified in
@gid.

All callers will grant less permissions to a user in case of failure of
this function and thus this change is safe.

In some cases it will be necessary to ignore errors reported from this
function. This allows suppressing them to avoid spamming logs.

Use 'cleanup' since it's also used on success.

When loading status XMLs with following graphics definition:

  <graphics type='spice' port='5900' autoport='yes' listen='127.0.0.1'>
    <listen type='address' address='127.0.0.1' fromConfig='1'/>
    <image compression='off'/>
  </graphics>

libvirtd would leak a few bytes:

10 bytes in 1 blocks are definitely lost in loss record 71 of 1,127
   at 0x4C2C000: malloc (vg_replace_malloc.c:299)
   by 0x6789298: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
   by 0x552AB0A: virXMLPropString (virxml.c:479)
   by 0x5539536: virDomainGraphicsListensParseXML (domain_conf.c:11171)
   by 0x553DD5E: virDomainGraphicsDefParseXMLSpice (domain_conf.c:11414)
   by 0x553DD5E: virDomainGraphicsDefParseXML (domain_conf.c:11749)
   by 0x5566061: virDomainDefParseXML (domain_conf.c:16939)
   by 0x556953F: virDomainObjParseXML (domain_conf.c:17348)
   by 0x556953F: virDomainObjParseNode (domain_conf.c:17513)
   by 0x5569902: virDomainObjParseFile (domain_conf.c:17532)
   by 0x5571E02: virDomainObjListLoadStatus (virdomainobjlist.c:514)
   by 0x5571E02: virDomainObjListLoadAllConfigs (virdomainobjlist.c:596)
   by 0x26E0BDC8: qemuStateInitialize (qemu_driver.c:911)
   by 0x55B1FDB: virStateInitialize (libvirt.c:770)
   by 0x122039: daemonRunStateInit (libvirtd.c:960)

s/succcess/success
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

For parsing a bitmap of an unknown size.

Most the callers pass 0 in one form or another, including
vircapstest which used VIR_ARCH_NONE.

This will be used for the caller that needs to specify a separator.
Currently identical to virBitmapParse.

Also change one test case to use the new function.

This is only used by one caller.

The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.

However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.

Avoid it completely, like it's already happening for q35.

Commit 2a58ed0b added support for creating guests with USB
hostdevs. Commit fc21d106 later added support for hotplut of
USB hostdevs. Advertise support for USB hostdevs in the
domcapabilities.

In addition add the appropriate caps for USB support on
domaincapstest when libvirt is built on a Xen with
LIBXL_HAVE_PVUSB. Otherwise domaincapstest would fail i.e.
testing the wrong domain capabilities.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>

Commit 409de00e changed the logic to only match PCI devices
while moving this before Remove*HostDevice calls.

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

There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.

Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.

This is fairly simple. We lookup the device in the array of
devices and remove it. No magic.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is really simple, we just need to append the device into the
domain def and that's it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is going to be important later when we received
DEVICE_DELETED event on the qemu monitor. If we do,
virDomainDefFindDevice() is called to find the device for given
device alias in the virDomainDef tree. When we enable removal for
redirdevs we need to include them in the lookup process too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Basically, there are just two functions introduced here:
virDomainRedirdevDefFind which looks up given redirdev in domain
definition, and virDomainRedirdevDefRemove which removes the
device at given index in the array of devices.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's currently just one limitation: redirdevs that want to go
on USB bus require a USB controller, surprisingly.
At the same time, since I'm using virDomainDefHasUSB() in this
new validator function, it has to be moved a few lines up and
also its header needed to be changed a bit: it is now taking a
const pointer to domain def since it's not changing anything in
there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Our current detection code uses just the number of CPU features which
need to be added/removed from the CPU model to fully describe the CPUID
data. The smallest number wins. But this may sometimes generate wrong
results as one can see from the fixed test cases. This patch modifies
the algorithm to prefer the CPU model with matching signature even if
this model results in a longer list of additional features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The CPU model was implemented in QEMU by commit f6f949e929.

The change to i7-5600U is wrong since it's a 5th generation CPU, i.e.,
Broadwell rather than Skylake, but that's just the result of our CPU
detection code (which is fixed by the following commit).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

While we need to know the difference between the total memory stored in
<memory> and the actual size not included in the possible memory modules
we can't pre-calculate it reliably. This is due to the fact that
libvirt's XML is copied via formatting and parsing the XML and the
initial memory size can be reliably calculated only when certain
conditions are met due to backwards compatibility.

This patch removes the storage of 'initial_memory' and fixes the helpers
to recalculate the initial memory size all the time from the total
memory size. This conversion is possible when we also make sure that
memory hotplug accounts properly for the update of the total memory size
and thus the helpers for inserting and removing memory devices need to
be tweaked too.

This fixes a bug where a cold-plug and cold-remove of a memory device
would increase the size reported in <memory> in the XML by the size of
the memory device. This would happen as the persistent definition is
copied before attaching the device and this would lead to the loss of
data in 'initial_memory'.

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

The parser was totaly broken. Fix it by rewriting it. Add tests so that
it doesn't happen.

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

A bug in the code used the value of the first perf event as state for
all the mentioned one rather than extracting individual ones.

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

When converting domXML to xen xl.cfg, backendtype should
not be emitted if <driver> is not specified. Moreover,
<driver name='file'/> should be converted to backendtype
qdisk, similar to handling of <driver> in libxlMakeDisk()
in libxl_conf.c.

Prior to this change, connectDomainXMLToNative would
produce incorrect xl.cfg when the input domXML contained
<driver name='file'/>

domXML:

  <disk type="file" device="disk">
    <driver name="file"/>
    <source file="/image/file/path"/>
    <target dev="xvda" bus="xen"/>
  </disk>

virsh domxml-to-native xen-xl domXML

disk = [ "format=raw,vdev=xvda,access=rw,backendtype=target=/image/file/path" ]

xl create xl.cfg
config parsing error in disk specification: unknown value
for backendtype: near `target=/image/file/path' in
`format=raw,vdev=xvda,access=rw,backendtype=target=/image/file/path'

Commit b3d06987 added peer address setting to the low level
virNetDevSetIPAddress() function, but ended up causing a segfault in
cases where the caller passed NULL for peer address.

Commit a3510e33 fixed the segfault, but managed to cause us to
skip setting the broadcast address when setting an interface's IP
address. The result is that the broadcast address is 0.0.0.0 for all
libvirt-created bridges (and interfaces in lxc containers with IP
addresses set by libvirt).

This was reported on the mailing list:

  https://www.redhat.com/archives/libvir-list/2016-June/msg00027.html

but I was too busy to investigate at the time. I found it by accident
today while refactoring virNetDevSetIPAddress(). Since this regression
is present in the 1.3.5 release, I'm sending the bugfix as a separate
patch from my larger refactoring patchset.

Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).

This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.

Previously there was no way to have a Q35 domain that didn't have
these two controllers. This patch skips their creation as long as
there are some other kinds of pci controllers at index 1 and 2
(e.g. some pcie-root-port controllers).

I'm hoping that soon we won't add them at all, plugging all devices
into auto-added pcie-*-port ports instead, but in the meantime this
makes it easier to experiment with alternative bus hierarchies.

Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Implement storage pool event callbacks for START, STOP, DEFINE, UNDEFINED
and REFRESHED in functions when a storage pool is created/started/stopped
etc. accordingly

Also includes unittests for storage pool lifecycle events API

Add storage event handling infrastructure to storage_event.[ch], following
the network_event.[ch] pattern.

Storage pool lifecycle event API entry points for registering and deregistering
storage pool events, as well as types of events associated with storage pools.
These entry points will be used for implementing asynchronous lifecycle events.

Storage pool API:
virConnectStoragePoolEventRegisterAny
virConnectStoragePoolEventDeregisterAny
virStoragePoolEventLifecycleType which has events STARTED, STOPPED, DEFINED,
UNDEFINED, and REFRESHED

Best viewed with -w since this is mostly just an indentation patch.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

Just create a helper for it and use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>