A new hidden command for virsh that will iterate over
all command groups and commands and print help for every single one.

This involves running vshCmddefOptParse so we can get an error if
one of the command's option structure is invalid.

This function generates some big random numbers.

Cache the result and supply it to any subsequent generate2 calls.

Since e8ac4a79 this test wastes some CPU cycles by blindly trying to
run almost every virsh command, blindly throwing away the output
and the return value and returning success if 'virsh help' successfully
returned at least one command.

Drop it completely.

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.

Whine about 'allowed_users' having wrong format rather than 'shell'

The list certainly isn't zero terminated and it would disallow usage of
group 'root'. Pass in the array size and match against it.

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>

Crash dump in a old kvmdump format is being obsolete and cannot be loaded and
processed by crash utility since its version 6.1.0. A --memory-only option is
required in order to produce valid ELF file which can be later processed by the
crash utility. A new note is added to the dump command description.

Use virBitmapParseUnlimited to parse the env variable.

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.

Similar to 'event' and 'net-event', this prints info about incoming
storage pool events.

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>

Unused since commit fb1e8d9c in May 2011.

This fixes building these backends when explicitly enabled
on the command line.

Exposed by commit a659559b which started adding
--with-storage-mpath in the spec file.

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

We have a test case that excercises the parser and formatter now which
takes part in schema checking so remove the schema-only test.

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>

Without that we might get similar messages in the log:

  error : virDriverLoadModule:73 : failed to load module
  /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so
  /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so: undefined
  symbol: virStorageFileCreate
Signed-off-by: NMartin Kletzander <mkletzan@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