Since its introduction in 81df2150 this variable was never
used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There is no need for this. None of the namespace helpers uses it.
Historically it was used when calling secdriver APIs, but we
don't to that anymore.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This struct is unused after 095f042e.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Again, one missed bit. This time without this commit there is no
/dev entry in the namespace of the qemu process when attaching
vhost SCSI device.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since we have qemuSecurity wrappers over
virSecurityManagerSetHostdevLabel and
virSecurityManagerRestoreHostdevLabel we ought to use them
instead of calling secdriver APIs directly.  Without those
wrappers the labelling won't be done in the correct namespace
and thus won't apply to the nodes seen by qemu itself.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

libvirt was able to set the host_mtu option when an MTU was explicitly
given in the interface config (with <mtu size='n'/>), set the MTU of a
libvirt network in the network config (with the same named
subelement), and would automatically set the MTU of any tap device to
the MTU of the network.

This patch ties that all together (for networks based on tap devices
and either Linux host bridges or OVS bridges) by learning the MTU of
the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and
returning that value so that it can then be passed to
qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the
interface's commandline options.

The result is that a higher MTU for all guests connecting to a
particular network will be plumbed top to bottom by simply changing
the MTU of the network (in libvirt's config for libvirt-managed
networks, or directly on the bridge device for simple host bridges or
OVS bridges managed outside of libvirt).

One question I have about this - it occurred to me that in the case of
migrating a guest from a host with an older libvirt to one with a
newer libvirt, the guest may have *not* had the host_mtu option on the
older machine, but *will* have it on the newer machine. I'm curious if
this could lead to incompatibilities between source and destination (I
guess it all depends on whether or not the setting of host_mtu has a
practical effect on a guest that is already running - Maxime?)

Likewise, we could run into problems when migrating from a newer
libvirt to older libvirt - The guest would have been told of the
higher MTU on the newer libvirt, then migrated to a host that didn't
understand <mtu size='blah'/>. (If this really is a problem, it would
be a problem with or without the current patch).

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

When working with symlinks it is fairly easy to get into a loop.
Don't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Similarly to one of the previous commits, we need to deal
properly with symlinks in hotplug case too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When working with symlinks it is fairly easy to get into a loop.
Don't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Imagine you have a disk with the following source set up:

/dev/disk/by-uuid/$uuid (symlink to) -> /dev/sda

After cbc45525 the transitive end of the symlink chain is
created (/dev/sda), but we need to create any item in chain too.
Others might rely on that.
In this case, /dev/disk/by-uuid/$uuid comes from domain XML thus
it is this path that secdriver tries to relabel. Not the resolved
one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After previous commit this has become redundant step.
Also setting up devices in namespace and setting their label
later on are two different steps and should be not done at once.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The idea is to move all the seclabel setting to security driver.
Having the relabel code spread all over the place looks very
messy.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Because of the nature of security driver transactions, it is
impossible to use them properly. The thing is, transactions enter
the domain namespace and commit all the seclabel changes.
However, in RestoreAllLabel() this is impossible - the qemu
process, the only process running in the namespace, is gone. And
thus is the namespace. Therefore we shouldn't use the transactions
as there is no namespace to enter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The current ordering is as follows:
1) set label
2) create the device in namespace
3) allow device in the cgroup

While this might work for now, it will definitely not work if the
security driver would use transactions as in that case there
would be no device to relabel in the domain namespace as the
device is created in the second step.
Swap steps 1) and 2) to allow security driver to use more
transactions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Now that we have a function for properly assigning the blockdeviotune
info, let's use it instead of dropping the group name on every
assignment.  Otherwise it will not work with both --live and --config
options.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

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

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

==12618== 110 bytes in 10 blocks are definitely lost in loss record 269 of 295
==12618==    at 0x4C2AE5F: malloc (vg_replace_malloc.c:297)
==12618==    by 0x1CFC6DD7: vasprintf (vasprintf.c:73)
==12618==    by 0x1912B2FC: virVasprintfInternal (virstring.c:551)
==12618==    by 0x1912B411: virAsprintfInternal (virstring.c:572)
==12618==    by 0x50B1FF: qemuAliasChardevFromDevAlias (qemu_alias.c:638)
==12618==    by 0x518CCE: qemuBuildChrChardevStr (qemu_command.c:4973)
==12618==    by 0x522DA0: qemuBuildShmemBackendChrStr (qemu_command.c:8674)
==12618==    by 0x523209: qemuBuildShmemCommandLine (qemu_command.c:8789)
==12618==    by 0x526135: qemuBuildCommandLine (qemu_command.c:9843)
==12618==    by 0x48B4BA: qemuProcessCreatePretendCmd (qemu_process.c:5897)
==12618==    by 0x4378C9: testCompareXMLToArgv (qemuxml2argvtest.c:498)
==12618==    by 0x44D5A6: virTestRun (testutils.c:180)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For example when both total_bytes_sec and total_bytes_sec_max are set,
but the former gets cleaned due to new call setting, let's say,
read_bytes_sec, we end up with this weird message for the command:

 $ virsh blkdeviotune fedora vda --read-bytes-sec 3000
 error: Unable to change block I/O throttle
 error: unsupported configuration: value 'total_bytes_sec_max' cannot be set if 'total_bytes_sec' is not set

So let's make it more descriptive.  This is how it looks after the change:

 $ virsh blkdeviotune fedora vda --read-bytes-sec 3000
 error: Unable to change block I/O throttle
 error: unsupported configuration: cannot reset 'total_bytes_sec' when 'total_bytes_sec_max' is set

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1344897Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Well, just two.  One indentation and the usage of 'ret'.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We were setting it based on whether it was supported and that lead to
setting it to NULL, which our JSON code caught.  However it ended up
producing the following results:

 $ virsh blkdeviotune fedora vda --total-bytes-sec-max 2000
 error: Unable to change block I/O throttle
 error: internal error: argument key 'group' must not have null value
Signed-off-by: NMartin Kletzander <mkletzan@redhat.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>

We lacked of timestamp in tainting of guests log,
which bring troubles for finding guest issues:
such as whether a guest powerdown caused by qemu-monitor-command
or others issues inside guests.
If we had timestamp in tainting of guests log,
it would be helpful when checking guest's /var/log/messages.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NJiri Denemark <jdenemar@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>

The event needs to be emitted after the last monitor call, so that it's
not possible to find the device in the XML accidentally while the vm
object is unlocked.

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

Previously when QEMU failed "drive_add" due to an error opening
a file it would report

  "could not open disk image"

These days though, QEMU reports

  "Could not open '/tmp/virtd-test_e3hnhh5/disk1.qcow2': Permission denied"

which we were not detecting as an error condition.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Move all the worker code into the appropriate file. This will also allow
testing of cpu hotplug.

Extract the call to qemuDomainSelectHotplugVcpuEntities outside of
qemuDomainSetVcpusLive and decide whether to hotplug or unplug the
entities specified by the cpumap using a boolean flag.

This will allow to use qemuDomainSetVcpusLive in cases where we prepare
the list of vcpus to enable or disable by other means.

In cases where CPU hotplug is supported by qemu force the monitor to
reject invalid or broken responses to 'query-cpus'. It's expected that
the command returns usable data in such case.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

While all the code that deals with qemu namespaces correctly
detects whether we are running as root (and turn into NO-OP for
qemu:///session) the actual unshare() call is not guarded with
such check. Therefore any attempt to start a domain under
qemu:///session shall fail as unshare() is reserved for root.

The fix consists of moving unshare() call (for which we have a
wrapper called virProcessSetupPrivateMountNS) into
qemuDomainBuildNamespace() where the proper check is performed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NRichard W.M. Jones <rjones@redhat.com>

This reverts commit ae16c95f.

When running on s390 with a kernel that does not support cpu model checking and
with a Qemu new enough to support query-cpu-model-expansion, the gathering of qemu
capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp
command with an error because the needed kernel ioct does not exist. When this
happens a guest cannot even be defined due to missing qemu capabilities data.

This patch fixes the problem by silently ignoring generic errors stemming from
calls to query-cpu-model-expansion.
Reported-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

When creating new /dev/* for qemu, we do chown() and copy ACLs to
create the exact copy from the original /dev. I though that
copying SELinux labels is not necessary as SELinux will chose the
sane defaults. Surprisingly, it does not leaving namespace with
the following labels:

crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0     random
crw-------. root root system_u:object_r:tmpfs_t:s0     rtc0
drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0     shm
crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0     urandom

As a result, domain is unable to start:

error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data.
qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data.

The solution is to copy the SELinux labels as well.
Reported-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>