Commit Graph

2104 Commits

Author SHA1 Message Date
Laine Stump
95089f481e util: assign tap device names using a monotonically increasing integer
When creating a standard tap device, if provided with an ifname that
contains "%d", rather than taking that literally as the name to use
for the new device, the kernel will instead use that string as a
template, and search for the lowest number that could be put in place
of %d and produce an otherwise unused and unique name for the new
device. For example, if there is no tap device name given in the XML,
libvirt will always send "vnet%d" as the device name, and the kernel
will create new devices named "vnet0", "vnet1", etc. If one of those
devices is deleted, creating a "hole" in the name list, the kernel
will always attempt to reuse the name in the hole first before using a
name with a higher number (i.e. it finds the lowest possible unused
number).

The problem with this, as described in the previous patch dealing with
macvtap device naming, is that it makes "immediate reuse" of a newly
freed tap device name *much* more common, and in the aftermath of
deleting a tap device, there is some other necessary cleanup of things
which are named based on the device name (nwfilter rules, bandwidth
rules, OVS switch ports, to name a few) that could end up stomping
over the top of the setup of a new device of the same name for a
different guest.

Since the kernel "create a name based on a template" functionality for
tap devices doesn't exist for macvtap, this patch for standard tap
devices is a bit different from the previous patch for macvtap - in
particular there was no previous "bitmap ID reservation system" or
overly-complex retry loop that needed to be removed. We simply find
and unused name, and pass that name on to the kernel instead of
"vnet%d".

This counter is also wrapped when either it gets to INT_MAX or if the
full name would overflow IFNAMSIZ-1 characters. In the case of
"vnet%d" and a 32 bit int, we would reach INT_MAX first, but possibly
someday someone will change the name from vnet to something else.

(NB: It is still possible for a user to provide their own
parameterized template name (e.g. "mytap%d") in the XML, and libvirt
will just pass that through to the kernel as it always has.)

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-01 14:16:44 -04:00
Laine Stump
d7f38beb2e util: replace macvtap name reservation bitmap with a simple counter
There have been some reports that, due to libvirt always trying to
assign the lowest numbered macvtap / tap device name possible, a new
guest would sometimes be started using the same tap device name as
previously used by another guest that is in the process of being
destroyed *as the new guest is starting.

In some cases this has led to, for example, the old guest's
qemuProcessStop() code deleting a port from an OVS switch that had
just been re-added by the new guest (because the port name is based on
only the device name using the port). Similar problems can happen (and
I believe have) with nwfilter rules and bandwidth rules (which are
both instantiated based on the name of the tap device).

A couple patches have been previously proposed to change the ordering
of startup and shutdown processing, or to put a mutex around
everything related to the tap/macvtap device name usage, but in the
end no matter what you do there will still be possible holes, because
the device could be deleted outside libvirt's control (for example,
regular tap devices are automatically deleted when the qemu process
terminates, and that isn't always initiated by libvirt but could
instead happen completely asynchronously - libvirt then has no control
over the ordering of shutdown operations, and no opportunity to
protect it with a mutex.)

But this only happens if a new device is created at the same time as
one is being deleted. We can effectively eliminate the chance of this
happening if we end the practice of always looking for the lowest
numbered available device name, and instead just keep an integer that
is incremented each time we need a new device name. At some point it
will need to wrap back around to 0 (in order to avoid the IFNAMSIZ 15
character limit if nothing else), and we can't guarantee that the new
name really will be the *least* recently used name, but "math"
suggests that it will be *much* less common that we'll try to re-use
the *most* recently used name.

This patch implements such a counter for macvtap/macvlan, replacing
the existing, and much more complicated, "ID reservation" system. The
counter is set according to whatever macvtap/macvlan devices are
already in use by guests when libvirtd is started, incremented each
time a new device name is needed, and wraps back to 0 when either
INT_MAX is reached, or when the resulting device name would be longer
than IFNAMSIZ-1 characters (which actually is what happens when the
template for the device name is "maccvtap%d"). The result is that no
macvtap name will be re-used until the host has created (and possibly
destroyed) 99,999,999 devices.

Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-09-01 14:16:36 -04:00
Roman Bogorodskiy
26a13ec469 bhyve: allow to specify host sound device
Allow to map sound playback and recording devices to host devices
using "<audio type='oss'/>" OSS audio backend.

Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-25 08:42:16 +04:00
Roman Bogorodskiy
9375bc7373 conf: allow to map sound device to host device
Introduce a new device element "<audio>" which allows
to map guest sound device specified using the "<sound>"
element to specific audio backend.

Example:

  <sound model='ich7'>
     <audio id='1'/>
  </sound>
  <audio id='1' type='oss'>
     <input dev='/dev/dsp0'/>
     <output dev='/dev/dsp0'/>
  </audio>

This block maps to OSS audio backend on the host using
/dev/dsp0 device for both input (recording)
and output (playback).

OSS is the only backend supported so far.

Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-25 08:42:16 +04:00
Peter Krempa
7a268c7c3a qemu: Move virQEMUFileOpenAs to qemu_domain.c
Commit 4362068979 moved the function to
util/virqemu.c which is compiled also on win32 and geteuid()/getegid()
doesn't exist there.

Move it to qemu_domain.c which is compiled only when the qemu driver is
enabled. Originally I didn't want to put it here as qemu_domain.c is a
code dump for helper functions but this is the least invasive fix.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-08-24 18:12:44 +02:00
Peter Krempa
4362068979 qemuOpenFileAs: Move into util/virqemu.c
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-08-24 16:40:42 +02:00
Ján Tomko
21cd1e7254 util: delete virStringListFree
Now that everything uses g_strfreev, this function is no longer
needed.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-03 15:37:36 +02:00
Ján Tomko
59ab98c112 util: virlog: unexport virLogVMessage
Last usage out of virlog.c was removed by
commit 91268c715c
    node_device_udev: remove deprecated logging function

Also drop the virbuffer.h include - it seems it was never used
for anything else than the transitive stdarg.h include.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-03 15:30:40 +02:00
Martin Kletzander
c8bb95912e util: Get rid of virFileFlock()
It was created to get rid of conditional compilation in the resctrl code and
make it usable anywhere else.  However this is not something that is going to be
used in other places because it is not portable and resctrl is just very
specific in this regard.  And there is no reason why there could not be a
preprocessor conditional in the resctrl code.  Also the interface of
virFileFlock() was very ambiguous which lead to some issues.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-08-03 10:57:47 +02:00
Wang Xin
493d2769f2 qemu: add support for shmem-{plain, doorbell} role
Role(master or peer) controls how the domain behaves on migration.
For more details about migration with ivshmem, see
https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/system/ivshmem.rst;hb=HEAD

It's a optional attribute in libvirt, and qemu will choose default
role for ivshmem device if the user is not specified.

With device property 'role', the value can be 'master' or 'peer'.
 - 'master' (means 'master=on' in qemu), the guest will copy
   the shared memory on migration to the destination host.
 - 'peer' (means 'master=off' in qemu), the migration is disabled.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Yang Hang <yanghang44@huawei.com>
Signed-off-by: Wang Xin <wangxinxin.wang@huawei.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-08-03 10:57:47 +02:00
Daniel P. Berrangé
7230bc95aa util: add a helper method for controlling the COW flag on btrfs
btrfs defaults to performing copy-on-write for files. This is often
undesirable for VM images, so we need to be able to control whether this
behaviour is used.

The virFileSetCOW() will allow for this. We use a tristate, since out of
the box, we want the default behaviour attempt to disable cow, but only
on btrfs, silently do nothing on non-btrfs. If someone explicitly asks
to disable/enable cow, then we want to raise a hard error on non-btrfs.

Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-07-23 16:18:08 +01:00
Michal Privoznik
228a27f59b security: Reintroduce virSecurityManager{Set,Restore}SavedStateLabel
These APIs were removed/renamed in v6.5.0-rc1~142 and v6.5.0-rc1~141
because they deemed unused. And if it wasn't for the RFE [1] things
would stay that way.

The RFE asks for us to not change DAC ownership on the file a domain is
restoring from. We have been doing that for ages (if not forever),
nevertheless it's annoying because if the restore file is on an NFS
remembering owner won't help - NFS doesn't support XATTRs yet. But more
importantly, there is no need for us to chown() the file because when
restoring the domain the file is opened and the FD is then passed to
QEMU. Therefore, we really need only to set SELinux and AppArmor.

This reverts bd22eec903.
This partially reverts 4ccbd207f2.

The difference to the original code is that secdrivers are now
not required to provide dummy implementation to avoid
virReportUnsupportedError(). The callback is run if it exists, if
it doesn't zero is returned without any error.

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

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-07-10 14:14:09 +02:00
Daniel Henrique Barboza
42036650c6 virhostcpu.c: introduce virHostCPUGetAvailableCPUsBitmap()
The idea is to have a function that calls virHostCPUGetOnlineBitmap()
but, instead of returning NULL if the host does not have CPU
offlining capabilities,  fall back to a bitmap containing all
present CPUs.

Next patch will use this helper in two other places.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-07-08 19:39:41 +02:00
Michal Privoznik
11d8ca9794 numa: expose HMAT APIs
These APIs will be used by QEMU driver when building the command
line.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-07-08 12:05:24 +02:00
Michal Privoznik
a89bbbac86 conf: Parse and format HMAT
To cite ACPI specification:

  Heterogeneous Memory Attribute Table describes the memory
  attributes, such as memory side cache attributes and bandwidth
  and latency details, related to the System Physical Address
  (SPA) Memory Ranges. The software is expected to use this
  information as hint for optimization.

According to our upstream discussion [1] this is exposed under
<numa/> as <cache/> under NUMA <cell/> and <latency> or
<bandwidth/> under numa/latencies.

1: https://www.redhat.com/archives/libvir-list/2020-January/msg00422.html

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-07-08 12:05:24 +02:00
Michal Privoznik
04bd77a19f conf: Move and rename virDomainParseScaledValue()
There is nothing domain specific about the function, thus it
should not have virDomain prefix. Also, the fact that it is a
static function makes it impossible to use from other files.
Move the function to virxml.c and drop the 'Domain' infix.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2020-07-08 12:05:24 +02:00
Shalini Chellathurai Saroja
5f9dd9d866 qemu: move ZPCI uid validation into device validation
The ZPCI device validation is specific to qemu. So, let us move the
ZPCI uid validation out of domain xml parsing into qemu domain device
validation.

Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-26 18:53:51 +02:00
Shalini Chellathurai Saroja
076591009a conf: fix zPCI address auto-generation on s390
Let us fix the issues with zPCI address validation and auto-generation
on s390.

Currently, there are two issues with handling the ZPCI address
extension. Firstly, when the uid is to be auto-generated with a
specified fid, .i.e.:

    ...
    <address type='pci'>
        <zpci fid='0x0000001f'/>
    </address>
    ...

we expect uid='0x0001' (or the next available uid for the domain).
However, we get a parsing error:

    $ virsh define zpci.xml
    error: XML error: Invalid PCI address uid='0x0000', must be > 0x0000
    and <= 0xffff

Secondly, when the uid is specified explicitly with the invalid
numerical value '0x0000', we actually expect the parsing error above.
However, the domain is being defined and the uid value is silently
changed to a valid value.

The first issue is a bug and the second one is undesired behaviour, and
both issues are related to how we (in-band) signal invalid values for
uid and fid. So let's fix the XML parsing to do validation based on what
is actually specified in the XML.

The first issue is also related to the current code behaviour, which
is, if either uid or fid is specified by the user, it is incorrectly
assumed that both uid and fid are specified. This bug is fixed by
identifying when the user specified ZPCI address is incomplete and
auto-generating the missing ZPCI address.

Signed-off-by: Bjoern Walk <bwalk@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2020-06-26 18:53:51 +02:00
Daniel P. Berrangé
e8645610c8 util: rename method to virKModIsProhibited
This new naming matches the terminology used in the error
messages that the callers report.

Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-26 15:39:33 +01:00
Daniel P. Berrangé
597fdabbc0 util: remove unused virKModConfig method
Using virKModConfig would not simplify any existing code.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-22 18:22:34 +01:00
Jonathon Jongsma
9691440ecb nodedev: add mdev support to virNodeDeviceCreateXML()
With recent additions to the node device xml schema, an xml schema can
now describe a mdev device sufficiently for libvirt to create and start
the device using the mdevctl utility.

Note that some of the the configuration for a mediated device must be
passed to mdevctl as a JSON-formatted file. In order to avoid creating
and cleaning up temporary files, the JSON is instead fed to stdin and we
pass the filename /dev/stdin to mdevctl. While this may not be portable,
neither are mediated devices, so I don't believe it should cause any
problems.

Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-19 10:39:55 +02:00
Jonathon Jongsma
c952d9cc1e nodedev: add support for mdev attributes
Mediated devices support arbitrary vendor-specific attributes that can
be attached to a mediated device. These attributes are ordered, and are
written to sysfs in order after a device is created. This patch adds
support for these attributes to the mdev data types and XML schema.

Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-19 10:39:54 +02:00
Michal Privoznik
4ccbd207f2 security: Rename virSecurityManagerRestoreSavedStateLabel()
The new name is virSecurityManagerDomainRestorePathLabel().

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-18 13:52:24 +02:00
Michal Privoznik
bd22eec903 security: Drop unused virSecurityManagerSetSavedStateLabel()
After previous commit this function is used no more.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-18 13:51:42 +02:00
Daniel Henrique Barboza
711a868861 numa_conf.c: add helper functions for cpumap operations
These helpers will be used in an auto-fill feature for incomplete
NUMA topologies in the next patch.

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-06-18 12:31:54 +02:00
Paulo de Rezende Pinatti
c5fffb959d util: Introduce a parser for kernel cmdline arguments
Introduce two utility functions to parse a kernel command
line string according to the kernel code parsing rules in
order to enable the caller to perform operations such as
verifying whether certain argument=value combinations are
present or retrieving an argument's value.

Signed-off-by: Paulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-06-16 09:43:34 +02:00
Michal Privoznik
dfa0e118f7 util: Move virIsDevMapperDevice() to virdevmapper.c
When introducing virdevmapper.c (in v4.3.0-rc1~427) I didn't
realize there is a function that calls in devmapper. The function
is called virIsDevMapperDevice() and lives in virutil.c. Now that
we have a special file for handling devmapper move it there.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
2020-06-15 14:50:46 +02:00
Jiri Denemark
a551dd5fdf hostcpu: Introduce virHostCPUGetSignature
The purpose of this function is to give a short description that would
be change when a host CPU is replaced with a different model. This is
currently implemented by reading /proc/cpuinfo.

It should be implemented for all architectures for which the QEMU driver
stores host CPU data in the capabilities cache. In other words for archs
that support host-model CPUs.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-05-25 16:09:41 +02:00
Peter Krempa
486bfba8b2 util: virqemu: Introduce virQEMUBuildNetdevCommandlineFromJSON
In preparation for converting the generator of -netdev to generate JSON
which will be used to do the command line rather than the other way
around we need to introduce a convertor which properly configures
virQEMUBuildCommandLineJSON for the quirks of -netdev.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-05-20 09:41:57 +02:00
Peter Krempa
9c9732d03a util: json: Introduce virJSONValueObjectAppendStringPrintf
Add a variant similar to virJSONValueObjectAppendString which also
formats more complex value strings with printf syntax.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-05-20 09:41:57 +02:00
Peter Krempa
003f063dd6 virCommand: Introduce virCommandGetArgList
The helper returns a list of arguments of a virCommand. This will be
useful in tests where we'll inspect certain already formatted arguments.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
2020-05-20 09:41:57 +02:00
Daniel Henrique Barboza
2d5f7a49ae qemu: Implement the IBS pSeries feature
This patch adds the implementation of the IBS pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_IBS capability added
in the previous patch.

IBS can have the following values: "broken", "workaround",
"fixed-ibs", "fixed-ccd" and "fixed-na".

This is the XML format for the cap:

<features>
  <ibs value='fixed-ibs'/>
</features>

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 14:43:13 +02:00
Daniel Henrique Barboza
104dadcff6 qemu: Implement the SBBC pSeries feature
This patch adds the implementation of the SBBC pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_SBBC capability added
in the previous patch.

Like the previously added CFPC feature, SBBC can have the values
"broken", "workaround" or "fixed". Extra code is required to handle
it since it's not a regular tristate capability.

This is the XML format for the cap:

<features>
  <sbbc value='workaround'/>
</features>

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 14:43:07 +02:00
Daniel Henrique Barboza
0280fc7270 qemu: Implement the CFPC pSeries feature
This patch adds the implementation of the CFPC pSeries feature,
using the QEMU_CAPS_MACHINE_PSERIES_CAP_CFPC capability added
in the previous patch.

CPFC can have the values "broken", "workaround" or "fixed". Extra
code is required to handle it since it's not a regular tristate
capability.

This is the XML format for the cap:

<features>
  <cfpc value='workaround'/>
</features>

Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-27 14:43:00 +02:00
Ján Tomko
d016a64de2 util: remove virRun
Everything is using virCommand now.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-23 12:49:30 +02:00
Julio Faracco
97a0aa2467 conf: Add <lease/> option for <dhcp/> settings
If an user is trying to configure a dhcp neetwork settings, it is not
possible to change the leasetime of a range or a host entry. This is
available using dnsmasq extra options, but they are associated with
dhcp-range or dhcp-hosts fields. This patch implements a leasetime for
range and hosts tags. They can be defined under that settings:

    <dhcp>
      <range ...>
        <lease/>
      </range>
      <host ...>
        <lease/>
      </host>
    </dhcp>

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

Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-23 10:59:23 +02:00
Jim Fehlig
b523e22521 xenconfig: Add support for 'passthrough' hypervisor feature
Add support for xl.cfg(5) 'passthrough' option in the domXML-to-xenconfig
configuration converter.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-04-21 09:21:42 -06:00
Michal Privoznik
55cbb94e2e security: Introduce virSecurityManagerDomainSetPathLabelRO
This API allows drivers to separate out handling of @stdin_path
of virSecurityManagerSetAllLabel(). The thing is, the QEMU driver
uses transactions for virSecurityManagerSetAllLabel() which
relabels devices from inside of domain's namespace. This is what
we usually want. Except when resuming domain from a file. The
file is opened before any namespace is set up and the FD is
passed to QEMU to read the migration stream from. Because of
this, the file lives outside of the namespace and if it so
happens that the file is a block device (i.e. it lives under
/dev) its copy will be created in the namespace. But the FD that
is passed to QEMU points to the original living in the host and
not in the namespace. So relabeling the file inside the namespace
helps nothing.

But if we have a separate API for relabeling the restore file
then the QEMU driver can continue calling
virSecurityManagerSetAllLabel() with transactions enabled and
call this new API without transactions.

We already have an API for relabeling a single file
(virSecurityManagerDomainSetPathLabel()) but in case of SELinux
it uses @imagelabel (which allows RW access) and we want to use
@content_context (which allows RO access).

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2020-04-17 16:24:30 +02:00
Michal Privoznik
5bc3299447 virDomainDriverGenerateMachineName: Factor out embed path hashing
The code that generates "qemu-embed-$hash" is going to be useful
in more places. Separate it out into a function.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-04-07 15:26:22 +02:00
Michal Privoznik
8b9488d929 conf: Move virDomainGenerateMachineName to hypervisor/
The virDomainGenerateMachineName() function doesn't belong in
src/conf/ really, because it has nothing to do with domain XML
parsing. It landed there because of lack of better place in the
past. But now that we have src/hypervisor/ the function should
live there. At the same time, the function name is changed to
match new location.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-04-07 15:26:19 +02:00
Rafael Fonseca
fc5925f1e0 util: introduce shared daemon startup code
Several daemons have similar code around general daemon startup code.
Let's move it into a file and share it among them.

Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-03-27 16:22:49 +01:00
Rafael Fonseca
d7e6dd0669 conf: domain_conf: remove virDomainVideoDefaultType
The logic has been moved to the individual drivers.

Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-03-25 09:31:35 +01:00
Rafael Fonseca
8ffc7e9190 util: remove virKeyFile
The functionality is now provided by glib's GKeyFile.

Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-03-23 15:36:02 +01:00
Peter Krempa
3b076391be conf: Add support for cookies for HTTP based disks
Add possibility to specify one or more cookies for http based disks.
This patch adds the config parser, storage and validation of the
cookies.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-03-16 15:51:44 +01:00
Ján Tomko
2245496d1c util: remove virStrerror
Now that we use g_strerror exclusively, remove this unused
function.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2020-03-13 17:26:55 +01:00
Daniel P. Berrangé
5c146f6e57 src: introduce an abstraction for running event loops
We want a way to easily run a private GMainContext in a
thread, with correct synchronization between startup
and shutdown of the thread.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-11 14:44:04 +00:00
Peter Krempa
09352cca2a VIR_FREE: Replace internals by g_clear_pointer
Our implementation masks GCC warnings of uninitialized use of the passed
argument. After changing this I got a load of following warnings:

src/conf/virnetworkportdef.c: In function 'virNetworkPortDefSaveStatus':
/usr/include/glib-2.0/glib/gmem.h:136:8: error: 'path' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  136 |     if (_p)                \
      |        ^
src/conf/virnetworkportdef.c:447:11: note: 'path' was declared here
  447 |     char *path;
      |           ^~~~

For the curious, g_clear_pointer is still safe for arguments with
side-effect. Here's the pre-processed output of trying to do a
VIR_FREE(*(test2++)):

 do {
     typedef char _GStaticAssertCompileTimeAssertion_1[(sizeof *(&(*(test2++))) == sizeof (gpointer)) ? 1 : -1] __attribute__((__unused__));
     __typeof__((&(*(test2++)))) _pp = (&(*(test2++)));
     __typeof__(*(&(*(test2++)))) _ptr = *_pp;

     *_pp = ((void *)0);
     if (_ptr)
        (g_free) (_ptr);
 } while (0) ;

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-03-05 16:22:27 +01:00
Daniel P. Berrangé
c85256b31b src: set the OS level thread name
Setting the thread name makes it easier to debug libvirtd
when many threads are running.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-05 12:23:02 +00:00
Ján Tomko
6607933984 conf: add virtiofs-related elements and attributes
Add more elements for tuning the virtiofsd daemon
and the vhost-user-fs device:

  <driver type='virtiofs' queue='1024' xattr='on'>
    <binary path='/usr/libexec/virtiofsd'>
      <cache mode='always'/>
      <lock posix='off' flock='off'/>
    </binary>
  </driver>

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Andrea Bolognani <abologna@redhat.com>
2020-03-04 12:08:50 +01:00
Jiri Denemark
768ecdcd4b qemu: Do not set default CPU for archs without CPU driver
Whenever there is a guest CPU configured in domain XML, we will call
some CPU driver APIs to validate the CPU definition and check its
compatibility with the hypervisor. Thus domains with guest CPU
specification can only be started if the guest architecture is supported
by the CPU driver. But we would add a default CPU to any domain as long
as QEMU reports it causing failures to start any domain on affected
architectures.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-02-26 12:16:32 +01:00