The slirp helper process should be associated with the VM cgroup, like
other helpers.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Don't stop the DBus daemon if a slirp helper failed to start, as it
may be shared with other helpers.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

When the job monitoring logic was refactored, these two commands
were not converted properly and the result is that a successful
dump or migration (char '0') would be reported as a failed one
(int 48) instead.

Fixes: dc0771cfReported-by: NBrian Rak <brak@gameservers.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Commit fadbaa23 introduced a stray parenthesis in formatdomain.html.in.
Remove it.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

libvirt depends on a ton of packages, so trying to install them
all by using the classic approach of repeatedly running configure
and reacting to each failure by installing the corresponding
missing package will inevitably lead to frustration.

Luckily there's an easy solution to get most dependencies
installed in one fell swoop, and we just need to document it.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@redhat.com>

Add a new test to check the 'mode' attribute of the passthrough element
and augment an existing, related test to check enablement of the
passthrough element only.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Add support for xl.cfg(5) 'passthrough' option in the domXML-to-xenconfig
configuration converter.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

'passthrough' is Xen-Specific guest configuration option new to Xen 4.13
that enables IOMMU mappings for a guest and hence whether it supports PCI
passthrough. The default is disabled. See the xl.cfg(5) man page and
xen.git commit babde47a3fe for more details.

The default state of disabled prevents hotlugging PCI devices. However,
if the guest configuration contains a PCI passthrough device at time of
creation, libxl will automatically enable 'passthrough' and subsequent
hotplugging of PCI devices will also be possible. It is not possible to
unconditionally enable 'passthrough' since it would introduce a migration
incompatibility due to guest ABI change. Instead, introduce another Xen
hypervisor feature that can be used to enable guest PCI passthrough

  <features>
    <xen>
      <passthrough state='on'/>
    </xen>
  </features>

To allow finer control over how IOMMU maps to guest P2M table, the
passthrough element also supports a 'mode' attribute with values
restricted to snyc_pt and share_pt, similar to xl.cfg(5) 'passthrough'
setting .
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

e820_host is a Xen-specific option, only available for PV domains, that
provides the domain a virtual e820 memory map based on the host one. It
is enabled with a new Xen hypervisor feature, e.g.

  <features>
    <xen>
      <e820_host state='on'/>
    </xen>
  </features>

e820_host is required when using PCI passthrough and is generally
considered safe for any PV kernel. e820_host is silently ignored if set
in HVM domain configuration. See xl.cfg(5) man page in the Xen
documentation for more details.
Signed-off-by: NMarek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>

We've moved most of our CI jobs to GitLab, so we should display
the corresponding badge prominently.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The file, added with commit

  commit 874952f8
  Author: Andrea Bolognani <abologna@redhat.com>
  Date:   Mon Apr 6 11:56:58 2020 +0200

    CONTRIBUTING: Add entry point for new contributors

should be included in release archives.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The udev monitor thread "udevEventHandleThread()" will lag the
actual/real view of devices in sysfs as it serially processes udev
monitor events. So for instance if you were to run the following cmd
to create a new veth pair and rename one of the veth endpoints

you might see the following monitor events and real world that looks like

                                     time
			              |    create v0 sysfs entry
wake udevEventHandleThread            |    create v1 sysfs entry
udev_monitor_receive_device(v1-add)   |    move v0 sysfs to v2
udevHandleOneDevice(v1)               |
udev_monitor_receive_device(v0-add)   |
udevHandleOneDevice(v0)               | <--- error msgs in virNetDevGetLinkInfo()
udev_monitor_receive_device(v2-move)  |      as v0 no longer exists
udevHandleOneDevice(v2)               |
                                     \/

As you can see the changes in sysfs can take place well before we get
to act on the events in the udevEventHandleThread(), so by the time we
get around to processing the v0 add event, the sysfs entry has been
moved to v2.

To work around this we check if the sysfs entry is valid before
attempting to read it and don't bother trying to read link info if
not. This is safe since we will never read sysfs entries earlier than
it existing, ie. if the entry is not there it has either been removed
in the time since we enumerated the device or something bigger is
busted, in either case, no sysfs entry, no link info. In the case
described above we will eventually get the link info as we work
through the queue of monitor events and get to the 'move' event.

https://bugzilla.redhat.com/show_bug.cgi?id=1557902Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

It is possible and common to rename some devices, this is especially
true for ethernet devices such as veth pairs.

In the udevEventHandleThread() we will be notified of this change but
currently we only process "add", "change" and "remove"
events. Renaming a device such as above results in a "move" event, not
a "remove" followed by and "add" or vise versa. This change will add
the new/destination device to our records but unfortunately there is
no usable mechanism to identify the old/source device to remove it
from the records. So this is admittedly only a partial fix.
Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Convert the simple example to Python 3 syntax:
- print() is a function
- do not use bare except
- libvirt.open*() does not return None but raises an exception

The referenced source for the example was removed with
5bb2a245Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Changes in the API:

 - APIs related to the graphics adapter are no longer on the
   IMachine interface, but on a IGraphicsAdapter interface
 - The LaunchVMProcess method takes a list of env variables
   instead of a single variable containing a concatenated
   list. Since we only ever pass a single env variable, we
   can simply stuff it straight into a list.
 - The DHCP server start method no longer needs the network
   name
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Changes in the API:

 - The CreatedSharedFolder method now accepts a target mount
   point. Since we don't request automount, we're just passing
   NULL. We could, however, use this to pass the desired
   mount target from the XML config in future.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Long ago we switched the vbox driver to run inside libvirtd to avoid
libvirt.so being polluted with GPLv2-only code. Since libvirtd is not
built on Windows, we disabled vbox on Windows builds. Thus the MSCOM
glue code is not required.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This is no longer supported since 2018/04
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This is no longer supported since 2017/05
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

While I'm at it, use more g_autofree and g_autoptr() in this
file. This also fixes a possible mem-leak in
virNetDevGetVirtualFunctions().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

I've just got a new machine and I'm still converging on the
kernel config. Anyway, since I don't have enabled any of SRIO-V
drivers, my kernel doesn't have NET_DEVLINK enabled (i.e.
virNetDevGetFamilyId() returns 0). But this makes nodedev driver
ignore all interfaces, because when enumerating all devices via
udev, the control reaches virNetDevSwitchdevFeature() eventually
and subsequently virNetDevGetFamilyId() which 'fails'. Well, it's
not really a failure - the virNetDevSwitchdevFeature() stub
simply returns 0.

Also, move the call a few lines below, just around the place
where it's needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Introduced in v3.8.0-rc1~96, the virNetDevGetFamilyId() gets
netlink family ID for passed family name (even though it's used
only for getting "devlink" ID). Nevertheless, the function
returns 0 on an error or if no family ID was found. This makes it
harder for a caller to distinguish these two. Change the retval
so that a negative value is returned upon error, zero is no ID
found (but no error encountered) and a positive value is returned
on successful translation.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This fixes build on mingw broken by my previous commit 36e12529.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

As explained in the previous commit, we need to relabel the file
we are restoring the domain from. That is the FD that is passed
to QEMU. If the file is not under /dev then the file inside the
namespace is the very same as the one in the host. And regardless
of using transactions, the file will be relabeled. But, if the
file is under /dev then when using transactions only the copy
inside the namespace is relabeled and the one in the host is not.
But QEMU is reading from the one in the host, actually.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1772838Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This commit partially reverts

    commit c360ea28
    Refs: v6.2.0-rc1-1-gc360ea28
    Author:     Rafael Fonseca <r4f4rfs@gmail.com>
    AuthorDate: Fri Mar 27 18:40:47 2020 +0100
    Commit:     Michal Prívozník <mprivozn@redhat.com>
    CommitDate: Mon Mar 30 09:48:22 2020 +0200

    util: virdaemon: fix compilation on mingw

    The daemons are not supported on Win32 and therefore were not compiled
    in that platform. However, with the daemon code sharing, all the code in
    utils *is* compiled and it failed because `waitpid`, `fork`, and
    `setsid` are not available. So, as before, let's not build them on
    Win32 and make the code more portable by using existing vir* wrappers.

Not compiling virDaemonForkIntoBackground on Win32 is good, but the
second part of the original patch incorrectly replaced waitpid and fork
with our virProcessWait and virFork APIs. These APIs are more than just
simple wrappers and we don't want any of the extra functionality.
Especially virFork would reset any setup made before
virDaemonForkIntoBackground is called, such as logging, signal handling,
etc.

As a result of the change the additional fix in v6.2.0-67-ga87e4788
(util: virdaemon: fix waiting for child processes) is no longer
needed and it is effectively reverted by this commit.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Improving the zPCI example by choosing more distinct values and
adding explanation for fid.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Changing the introduction to bring the idea of this document better across.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>