Now that we have everything prepared let the fun begin. This
completer is very simple and returns domain names. Moreover,
depending on the command it can return just a subset of domains
(e.g. only running/paused/transient/.. ones).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The only purpose of this file is to be sourced. After that one
can use completion even for their bash:

  # virsh list --<TAB><TAB>
  --all                   --inactive ...
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This command is going to be called from bash completion script in
the following form:

  virsh complete -- start --domain

Its only purpose is to return list of possible strings for
completion. Note that this is a 'hidden', unlisted command and
therefore there's no documentation to it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Similarly to the previous commit, once we've presented an
--option for a command to the user it makes no sense to offer it
again. Therefore, we can prune all already specified options. For
instance, after this patch:

  virsh # migrate --verbose <TAB><TAB>

will no longer offer --verbose option.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of having completers prune returned string list based on
user's input we can do that right after the callback is called.
Only strings matching the prefix will be presented to the user
then.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we have everything prepared we can call options'
completer again. At the same time, pass partially parsed input to
the completer callback - it will help the callbacks to narrow
down the list of returned options based on user's input. For
instance, if the completer is supposed to return list of
interfaces depending on user input it may return just those
interfaces defined for already specified domain. Of course,
completers might ignore this parameter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The first argument passed to this function is vshControl *.
There's no need to use void pointer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For two string lists merge one into the other one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the future, completer callbacks will receive partially parsed
command (and thus possibly incomplete). However, we still want
them to use command options fetching APIs we already have (e.g.
vshCommandOpt*()) and at the same time don't report any errors
(nor call any asserts).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It's better to fetch list of either commands or options just once
and then iterate over it. Moreover, it makes future completers
way simpler as they will return string lists too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When returning a string that needs escaping there are two
scenarios that can happen. Firstly, user already started the
string with a quote (or double quote) in which case we don't need
to do anything - readline takes care of that. However, if they
haven't typed anything yet, we need to escape the string
ourselves.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we have a way of retrieving partly parsed command we
don't need duplicate code that parses the user's input.

Yes, this code removes call of opt's completer, but:
  a) current implementation is broken anyway, and
  b) it will be added back shortly
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the future, this function is going to be called from
vshReadlineParse() to provide parsed input for completer
callbacks. The idea is to allow the callbacks to provide more
specific data. For instance, for the following input:

  virsh # domifaddr --domain fedora --interface <TAB><TAB>

the --interface completer callback is going to be called. Now, it
is more user friendly if the completer offers only those
interfaces found in 'fedora' domain. But in order to do that it
needs to be able to retrieve partially parsed result.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When parsing cmd line which has "--" on it, this is leaked.
Problem is, parser->getNextArg() allocates new string and stores
it into tkdata. But as soon as "--" is detected 'continue' is
issued without any free of the allocated memory.

  ==5304== 3 bytes in 1 blocks are definitely lost in loss record 1 of 782
  ==5304==    at 0x4C2AF50: malloc (vg_replace_malloc.c:299)
  ==5304==    by 0x8BB5AA9: strdup (strdup.c:42)
  ==5304==    by 0x55842CA: virStrdup (virstring.c:941)
  ==5304==    by 0x172B21: _vshStrdup (vsh.c:162)
  ==5304==    by 0x175E8E: vshCommandArgvGetArg (vsh.c:1622)
  ==5304==    by 0x17551D: vshCommandParse (vsh.c:1418)
  ==5304==    by 0x175F25: vshCommandArgvParse (vsh.c:1638)
  ==5304==    by 0x130940: virshParseArgv (virsh.c:820)
  ==5304==    by 0x130C49: main (virsh.c:922)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

All our internal *Free() functions are capable of handling NULL.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

All our internal *Free() functions are capable of handling NULL.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Update the text to include "luks" as a possible value.

distcheck, and possibly more stuff, breaks because of it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Let's add a testcase for a S390 system running kernel version 4.14 on
LPAR.
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Since kernel version 4.7, processor frequency information is available
on S390. Let's adjust the parser so this information shows up for virsh
nodeinfo:

    # virsh nodeinfo
    CPU model:           s390x
    CPU(s):              8
    CPU frequency:       5000 MHz
    CPU socket(s):       1
    Core(s) per socket:  8
    Thread(s) per core:  1
    NUMA cell(s):        1
    Memory size:         16273908 KiB
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

Alter the volume logic to use the hash tables instead of forward
linked lists. There are three hash tables to allow for fast lookup
by name, target.path, and key.

Modify the virStoragePoolObjAddVol to place the object in all 3
tables if possible using self locking RWLock on the volumes object.
Conversely when removing the volume, it's a removal of the object
from the various hash tables.

Implement functions to handle remote ForEach and Search Volume
type helpers. These are used by the disk backend in order to
facilitate adding a primary, extended, or logical partition.

Implement the various VolDefFindBy* helpers as simple (and fast)
hash lookups. The NumOfVolumes, GetNames, and ListExport helpers
are all implemented using standard for each hash table calls.

Prepare for hash table volume lists by creating the object infrastructure
for a Volume Object and Volume Object List

The _virStorageVolObj will contain just a pointer to the "current"
(and live) volume definition.

The _virStorageVolObjList will contain three hash tables, one for
each of the lookup options allowed for a volume.

Alter the logic such that we only add the volume to the pool once
we've filled in all the information and cause failure to go to a
common error: label. Patches to place the @vol into a few hash tables
will soon "require" that at least the keys (name, target.path, and key)
be populated with valid data.

For a disk backend, the deleteVol code will clear all the
volumes in the pool and perform a pool refresh, thus the
storageVolDeleteInternal should not use access @voldef
after deleteVol succeeds.

When specifying a new CPU model in cpu_map.xml as an extension to an
existing model, we forgot to copy the signature (family + model) from
the original CPU model.

We don't use this way of specifying CPU models, but it's still supported
and it becomes useful when someone wants to quickly hack up a CPU model
for testing or when creating additional variants of existing models to
help with fixing some spectral issues.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

When translating CPUID data into CPU model + features, the code
sometimes uses an unexpected CPU model. There may be several reasons for
this, starting with wrong expectations and ending with an actual bug in
our code. These debug messages will help determining the reason.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The cpuidMap in cpu-cpuid.py was created for converting old data files
(with QEMU's feature-words bits) to the new model-expansion based data.
When I added tests for CPU live update based on disabled/enabled feature
lists I shamelessly used the existing cpuidMap for generating the
*-{enabled,disabled}.xml data files. Thus any new CPUID bits which are
not present in the original cpuidMap would be ignored. The correct thing
to do is to use cpu_map.xml.

All data files were fixed by running the following command:

    ./cpu-cpuid.py diff *.json
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This is now covered by DomainSetPathLabel being implemented in apparmor.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Since 1b4f66ec "security: introduce virSecurityManager
(Set|Restore)ChardevLabel" this is a public API of security manager.

Implementing this in apparmor avoids miss any rules that should be
added for devices labeled via these calls.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

virSecurityManagerDomainSetPathLabel is used to make a path known
to the security modules, but today is used interchangably for
 - paths to files/dirs to be accessed directly
 - paths to a dir, but the access will actually be to files therein

Depending on the security module it is important to know which of
these types it will be.

The argument allowSubtree augments the call to the implementations of
DomainSetPathLabel that can - per security module - decide if extra
actions shall be taken.

For now dac/selinux handle this as before, but apparmor will make
use of it to add a wildcard to the path that was passed.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This came up in discussions around huge pages, but it will cover
more per guest paths that should be added to the guests apparmor profile:
 - keys via qemuDomainWriteMasterKeyFile
 - per domain dirs via qemuProcessMakeDir
 - memory backing paths via qemuProcessBuildDestroyMemoryPathsImpl
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Required to generate correct profiles when using usb passthrough.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/565691Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: NJamie Strandboge <jamie@ubuntu.com>
Acked-by: NIntrigeri <intrigeri@boum.org>

This is required for the ebtables functionality added in
libvirt 0.8.0.
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

While libvirtd might do so, qemu itself as a guest will not need
to call qemu-nbd so remove it from the profile.
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

Adding the PKI path that is used as default suggestion in src/qemu/qemu.conf
If people use non-default paths they should use local overrides but the
suggested defaults we should open up.

This is the default path as referenced by src/qemu/qemu.conf in libvirt.

While doing so merge the several places we have to cover PKI access into
one.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1690140Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Allows (multi-arch enabled) access to libraries under the
/usr/lib/@{multiarch}/qemu/*.so path in the Debian/Ubuntu
qemu-block-extra package and all such libs for the paths
of rpm qemu-block-* packages.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1554761Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Prevent denial messages related to attempted reads on lttng
files from spamming the logs.

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1432644Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

Bug-Ubuntu: https://bugs.launchpad.net/bugs/1393548Signed-off-by: NStefan Bader <stefan.bader@canonical.com>

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

Users might use a block device as UEFI VAR store. Or even have
OVMF stored there. Therefore, when starting a domain and separate
mount namespace is used, we have to create all the /dev entries
that are configured for the domain.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>