[libvirt] [PATCH v5] util: Set SIGPIPE to a no-op handler in virFork
by Wang Yechao
Libvirtd has set SIGPIPE to ignored, and virFork resets all signal
handlers to the defaults. But child process may write logs to
stderr/stdout, that may generate SIGPIPE if journald has stopped.
So set SIGPIPE to a dummy no-op handler before unmask signals in
virFork. And there is no need to set SIGPIPE ignored before running
hooks in virExec. At last, set SIGPIPE to defaults before execve.
Signed-off-by: Wang Yechao <wang.yechao255(a)zte.com.cn>
---
v3 patch:
https://www.redhat.com/archives/libvir-list/2019-October/msg00934.html
Changes in v4:
- don't block SIGPIPE, ignore it when invoke VIR_FORCE_CLOSE and virCommandMassClose
Changes in v5:
- chang from SIG_IGN to a no-op handler in child process
---
src/util/vircommand.c | 27 ++++++++++-----------------
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/src/util/vircommand.c b/src/util/vircommand.c
index 93b3dd2..c13739c 100644
--- a/src/util/vircommand.c
+++ b/src/util/vircommand.c
@@ -217,6 +217,8 @@ virCommandFDSet(virCommandPtr cmd,
#ifndef WIN32
+static void virDummyHandler(int sig G_GNUC_UNUSED) {}
+
/**
* virFork:
*
@@ -312,6 +314,9 @@ virFork(void)
ignore_value(sigaction(i, &sig_action, NULL));
}
+ sig_action.sa_handler = virDummyHandler;
+ ignore_value(sigaction(SIGPIPE, &sig_action, NULL));
+
/* Unmask all signals in child, since we've no idea what the
* caller's done with their signal mask and don't want to
* propagate that to children */
@@ -550,7 +555,7 @@ virExec(virCommandPtr cmd)
g_autofree char *binarystr = NULL;
const char *binary = NULL;
int ret;
- struct sigaction waxon, waxoff;
+ struct sigaction sig_action;
g_autofree gid_t *groups = NULL;
int ngroups;
@@ -718,21 +723,6 @@ virExec(virCommandPtr cmd)
}
}
- /* virFork reset all signal handlers to the defaults.
- * This is good for the child process, but our hook
- * risks running something that generates SIGPIPE,
- * so we need to temporarily block that again
- */
- memset(&waxoff, 0, sizeof(waxoff));
- waxoff.sa_handler = SIG_IGN;
- sigemptyset(&waxoff.sa_mask);
- memset(&waxon, 0, sizeof(waxon));
- if (sigaction(SIGPIPE, &waxoff, &waxon) < 0) {
- virReportSystemError(errno, "%s",
- _("Could not disable SIGPIPE"));
- goto fork_error;
- }
-
if (virProcessSetMaxMemLock(0, cmd->maxMemLock) < 0)
goto fork_error;
if (virProcessSetMaxProcesses(0, cmd->maxProcesses) < 0)
@@ -783,7 +773,10 @@ virExec(virCommandPtr cmd)
if (virCommandHandshakeChild(cmd) < 0)
goto fork_error;
- if (sigaction(SIGPIPE, &waxon, NULL) < 0) {
+ memset(&sig_action, 0, sizeof(sig_action));
+ sig_action.sa_handler = SIG_DFL;
+ sigemptyset(&sig_action.sa_mask);
+ if (sigaction(SIGPIPE, &sig_action, NULL) < 0) {
virReportSystemError(errno, "%s",
_("Could not re-enable SIGPIPE"));
goto fork_error;
--
1.8.3.1
5 years, 1 month
[libvirt] [PATCH] cpu_map: Ship arm_features.xml
by Andrea Bolognani
The file was introduced in be03587a3446, but it was not added
to $(cpumap_DATA) at the time and so it didn't show up in the
distribution archive.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed under the build breaker rule.
src/cpu_map/Makefile.inc.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/cpu_map/Makefile.inc.am b/src/cpu_map/Makefile.inc.am
index ce8a311e22..7eb86c8fc7 100644
--- a/src/cpu_map/Makefile.inc.am
+++ b/src/cpu_map/Makefile.inc.am
@@ -2,6 +2,7 @@
cpumapdir = $(pkgdatadir)/cpu_map
cpumap_DATA = \
+ cpu_map/arm_features.xml \
cpu_map/index.xml \
cpu_map/ppc64_vendors.xml \
cpu_map/ppc64_POWER7.xml \
--
2.21.0
5 years, 1 month
[libvirt] [PATCH 00/11] qemu: Add support for ARM CPU features
by Andrea Bolognani
Starting with QEMU 4.2.0, ARM guests support CPU features similarly
to what's been the case on x86 since forever; notably, it's now
possible to enable SVE (Scalable Vector Extension).
Some of the patches in the series (notably 1/11) are snipped; the
unabridged version can be obtained with
$ git fetch https://gitlab.com/abologna/libvirt.git sve
Andrea Bolognani (11):
tests: Update capabilities for QEMU 4.2.0 on aarch64
qemu: Rename virQEMUCapsObjectPropsMaxX86CPU
qemu: Introduce QEMU_CAPS_ARM_MAX_CPU
qemu: Query max-arm-cpu properties
qemu: Update query-cpu-model-expansion check
qemu: Perform full expansion on ARM
cpu_map: Introduce ARM CPU features
cpu: Validate ARM CPU features
qemu: Validate ARM CPU features
tests: Introduce tests for ARM CPU features
news: Update for ARM CPU features
docs/news.xml | 9 +
src/cpu/cpu_arm.c | 157 +
src/cpu_map/arm_features.xml | 22 +
src/cpu_map/index.xml | 4 +
src/qemu/qemu_capabilities.c | 20 +-
src/qemu/qemu_capabilities.h | 3 +
src/qemu/qemu_command.c | 3 +-
src/qemu/qemu_domain.c | 37 +
.../qemu_4.2.0-virt.aarch64.xml | 2 +-
tests/domaincapsdata/qemu_4.2.0.aarch64.xml | 2 +-
.../caps_2.12.0.aarch64.replies | 159 +-
.../caps_2.12.0.aarch64.xml | 1 +
.../caps_4.0.0.aarch64.replies | 159 +-
.../caps_4.0.0.aarch64.xml | 1 +
.../caps_4.2.0.aarch64.replies | 3755 ++++++++++-------
.../caps_4.2.0.aarch64.xml | 52 +-
.../aarch64-features-sve-disabled.xml | 18 +
.../aarch64-features-sve.aarch64-latest.args | 32 +
.../qemuxml2argvdata/aarch64-features-sve.xml | 20 +
.../aarch64-features-wrong.xml | 17 +
tests/qemuxml2argvtest.c | 9 +
.../aarch64-features-sve.aarch64-latest.xml | 31 +
tests/qemuxml2xmltest.c | 3 +
23 files changed, 3029 insertions(+), 1487 deletions(-)
create mode 100644 src/cpu_map/arm_features.xml
create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve-disabled.xml
create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.aarch64-latest.args
create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.xml
create mode 100644 tests/qemuxml2argvdata/aarch64-features-wrong.xml
create mode 100644 tests/qemuxml2xmloutdata/aarch64-features-sve.aarch64-latest.xml
--
2.21.0
5 years, 1 month
[libvirt] [PATCHv2 0/2] util: set bridge device MAC address explicitly
by Laine Stump
From: Laine Stump <laine(a)redhat.com>
I just sent a single patch for this, then realized there was a small
prerequisite patch also needed. So 1/2 is the prerequisite patch, and 2/2 is identical to the single patch I sent previously.
Laine Stump (2):
util: allow sending mac addr to virNetNewLink without ifindex
util: set bridge device MAC address explicitly during
virNetDevBridgeCreate
src/network/bridge_driver.c | 2 +-
src/util/virnetdevbridge.c | 43 ++++++++++++++++++++++++++++++-------
src/util/virnetdevbridge.h | 2 +-
src/util/virnetlink.c | 9 ++++++--
4 files changed, 44 insertions(+), 12 deletions(-)
--
2.23.0
5 years, 1 month
[libvirt] [PATCH RFC 00/11] qemu: Introduce support for ARM CPU features
by Andrea Bolognani
This series is RFC because the corresponding QEMU patches[1] have
not been merged yet, and since QEMU is currently in the middle of
the 4.1.0 freeze we can't really expect to merge them until 5.7.0
anyway.
With that in mind, a few patches are somewhat independent of the
rest and could, after some minor tweaking, could go in even right
now: 1/11 is really a no brainer, and 3/11 - 5/11 are also fairly
reasonable candidates for that treatment.
[1] https://lists.nongnu.org/archive/html/qemu-devel/2019-06/msg04945.html
Andrea Bolognani (11):
tests: Update replies for QEMU 2.12.0 on aarch64
tests: Add replies for QEMU 4.1.0 on aarch64
qemu: Rename virQEMUCapsObjectPropsMaxX86CPU
qemu: Introduce QEMU_CAPS_ARM_MAX_CPU
qemu: Query max-arm-cpu properties
qemu: Update query-cpu-model-expansion check
qemu: Perform full expansion on ARM
cpu_map: Introduce ARM CPU features
cpu: Validate ARM CPU features
tests: Introduce tests for ARM CPU features
news: Update for ARM CPU features
docs/news.xml | 9 +
src/cpu/cpu_arm.c | 171 ++
src/cpu_map/arm_features.xml | 21 +
src/cpu_map/index.xml | 4 +
src/qemu/qemu_capabilities.c | 18 +-
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 3 +-
.../caps_2.12.0.aarch64.replies | 324 ++-
.../caps_2.12.0.aarch64.xml | 5 +-
.../caps_4.0.0.aarch64.replies | 159 +-
.../caps_4.0.0.aarch64.xml | 1 +
...h64.replies => caps_4.1.0.aarch64.replies} | 2205 ++++++++++-------
...0.0.aarch64.xml => caps_4.1.0.aarch64.xml} | 53 +-
.../aarch64-features-sve.aarch64-latest.args | 32 +
.../qemuxml2argvdata/aarch64-features-sve.xml | 20 +
.../aarch64-features-wrong.xml | 17 +
tests/qemuxml2argvtest.c | 7 +
17 files changed, 2085 insertions(+), 965 deletions(-)
create mode 100644 src/cpu_map/arm_features.xml
copy tests/qemucapabilitiesdata/{caps_4.0.0.aarch64.replies => caps_4.1.0.aarch64.replies} (96%)
copy tests/qemucapabilitiesdata/{caps_4.0.0.aarch64.xml => caps_4.1.0.aarch64.xml} (80%)
create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.aarch64-latest.args
create mode 100644 tests/qemuxml2argvdata/aarch64-features-sve.xml
create mode 100644 tests/qemuxml2argvdata/aarch64-features-wrong.xml
--
2.21.0
5 years, 1 month
[libvirt] Availability of libvirt 5.9.0
by Daniel Veillard
With a bit of delay I finally made the release today, it's available
as signed tarball and source rpms from the usual place:
https://libvirt.org/sources/
I also pushed a python release which is virtually identical to 5.8.0 one
but you can find it at
https://libvirt.org/sources/python/
You can start to see in this release some of the long term changes which
were raised last month:
Packaging changes
- Start linking against GLib and using its features
Up until now, libvirt has been dealing with platform portability and
the lack of certain features in libc by using gnulib and implementing
its own functions and data structures respectively; going forward, it
will prefer the facilities offered by GLib instead.
- Stop distributing generated documentation
Most downstreams already patch the libvirt source to some extent, so
this change will probably not affect them.
- Rewrite several Perl scripts in Python
Phasing out Perl usage is part of the project strategy.
New features
- qemu: Introduce a new video model of type 'ramfb'
Introduce a new video model type to the domain XML that supports the
ramfb standalone device in qemu.
- qemu: Implement the ccf-assist pSeries feature
Users can now decide whether ccf-assist (Count Cache Flush Assist)
support should be available to pSeries guests.
- Xen: Support specifying ACPI firmware path
The libxl driver now supports specifying an ACPI firmware path using
the acpi element.
- qemu: Support specifying resolution for video devices
Removed features
- logging: Drop support for including stack traces
This feature was intended to aid debugging, but in practice it resulted
in logs that were too verbose to be useful and also resulted in a
significant performance penalty.
Improvements
- qemu: Implement CPU comparison/baseline on s390x
This functionality has been historically limited to x86_64, but it's
now available on s390x too.
Bug fixes
- lib: autostart objects exactly once
If libvirtd or any of the sub-daemons is started with socket activation
then objects might be autostarted more than once. For instance, if a
domain under qemu:///session URI is mark as autostarted and the session
daemon is started then the domain is started with it. If user shuts the
domain down and the session daemon is started again, the user's wish to
keep the domain shut off is ignored and the domain is autostarted
again. This is now fixed.
- qemu: Properly advertise bochs-display availability
Support for bochs-display was introduced in libvirt 5.6.0, but until
now the model was not listed in the domain capabilities.
- security: Don't remember labels for TPM devices
Due to the way they're implemented in the kernel, trying to remember
labels for TPM devices makes it impossible to use them.
- security: Properly rollback after failure in a stacked driver
When multiple security drivers are involved, failure in one of them
would result in only the corresponding changes being rolled back,
leaving the ones performed by drivers that had been activated earlier
in place. All changes are rolled back now.
- Fix build with musl libc
- Improve compatibility with non-bash shells
thanks everybody who helped with this release, next in a month !
Enjoy :-)
Daniel
--
Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/
veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | virtualization library http://libvirt.org/
5 years, 1 month
[libvirt] [PATCH] maint: Post-release version bump to 5.10.0
by Andrea Bolognani
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
configure.ac | 2 +-
docs/news.xml | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 8b53b6ada9..233fbeaaf3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -16,7 +16,7 @@ dnl You should have received a copy of the GNU Lesser General Public
dnl License along with this library. If not, see
dnl <http://www.gnu.org/licenses/>.
-AC_INIT([libvirt], [5.9.0], [libvir-list(a)redhat.com], [], [https://libvirt.org])
+AC_INIT([libvirt], [5.10.0], [libvir-list(a)redhat.com], [], [https://libvirt.org])
AC_CONFIG_SRCDIR([src/libvirt.c])
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([config.h])
diff --git a/docs/news.xml b/docs/news.xml
index d770e88eb0..4dd8dd6dcc 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -42,6 +42,14 @@
-->
<libvirt>
+ <release version="v5.10.0" date="unreleased">
+ <section title="New features">
+ </section>
+ <section title="Improvements">
+ </section>
+ <section title="Bug fixes">
+ </section>
+ </release>
<release version="v5.9.0" date="2019-11-05">
<section title="Packaging changes">
<change>
--
2.21.0
5 years, 1 month
Re: [libvirt] [PATCH v3 REBASE 2 00/12] hostdev: handle usb detach/attach on node
by Dave Allan
[ bah, cc'ing the list this time ]
On Tue, Nov 05, 2019 at 03:21:04PM -0500, Dave Allan wrote:
>On Fri, Nov 01, 2019 at 07:48:46AM +0000, Nikolay Shirokovskiy wrote:
>>
>>
>>On 31.10.2019 19:50, Dave Allan wrote:
>>>On Thu, Oct 31, 2019 at 10:40:42AM +0000, Nikolay Shirokovskiy wrote:
>>>>
>>>>
>>>>On 30.10.2019 23:21, Dave Allan wrote:
>>>>>On Tue, Oct 29, 2019 at 11:17:51AM +0300, Nikolay Shirokovskiy wrote:
>>>>>>Diff to v2[1] version:
>>>>>>- add 'replug' attribute for hostdev element to allow replug semantics
>>>>>>- avoid accuiring domain lock in event loop thread on udev events as
>>>>>> suggested by Peter
>>>>>>- nit picks after review by Daniel Henrique Barboza
>>>>>>
>>>>>>* is used to mark patches that were 'Reviewed-by' by Daniel (sometimes
>>>>>> with very minor changes to take into account new replug flag).
>>>>>
>>>>>I did some basic testing today, and I'm seeing the device appear and disappear in the guest, which is great and much nicer than my ugly udev rule hack. I did find what I think is a bug though: if the USB device is plugged in at domain start, unplugging it while the domain is running does not cause it to disappear, and subsqeuently replugging it into the host causes a second instance of the device to appear in the guest.
>>>>
>>>>Hi.
>>>>
>>>>Hmm. Looks like you're using startupPolicy=optional otherwise it is not
>>>>possible to start domain without a device. But in this case the whole replug thing
>>>>is disabled and further I don't understand how the second instance of the device can appear.
>>>>
>>>>If device is present at domain start then replug is in play. And I cannot reproduce the bug.
>>>
>>>I am using startupPolicy optional, and I'm seeing the device attached and detached 100% of the time. I can start the domain with or without the device attached to the host, plug and unplug it and it appears and disappears from the guest, which is exactly the behavior I want. My domain XML is attached.
>>
>>Hi,
>>
>>did you actually see your device in guest or just some usb device? Because if domain is started without a device present on host then
>>libvirt inserts dummy device which is unusable actually. And this dummy device is kept until the end even if you plug device on node.
>
>Sorry to be slow responding, I wanted to confirm that I could talk to the device in the guest. Today I wasn't able to reproduce the duplicate device in the guest. Eerything worked as I would expect: if the device wasn't plugged into the host, it wasn't shown by lsusb in the guest. Plugging in the device to the host caused it to appear in the guest. If the device was shown by lsusb in the guest I was able to talk to it.
>
>>Nikolay
>>
>>>
>>>I tested a few more times just now, and I saw the duplicate device appear in the guest the first time I tried, but I have not been able to reproduce it again after that.
>>>
>>>>Can you clarify on you use case?
>>>
>>>My usecase is that I'm flashing the USB device with a program running in the VM. I keep the VM running, and when I need to reflash, I connect the device, so having the startupPolicy optional is useful.
>>>
>>>>Nikolay
>>>>
>>>>>
>>>>>>Can be applied on:
>>>>>>
>>>>>>commit bf0e7bdeeb790bc6ba5732623be0d9ff26a5961a
>>>>>>Author: Peter Krempa <pkrempa(a)redhat.com>
>>>>>>Date: Thu Oct 24 15:50:50 2019 +0200
>>>>>>
>>>>>> util: xml: Make virXMLFormatElement void
>>>>>>[1] https://www.redhat.com/archives/libvir-list/2019-September/msg00321.html
>>>>>>
>>>>>>Nikolay Shirokovskiy (12):
>>>>>> conf: add replug option for usb hostdev
>>>>>> qemu: track hostdev delete intention
>>>>>> *qemu: support host usb device unplug
>>>>>> *qemu: support usb hostdev plugging back
>>>>>> qemu: handle host usb device add/del udev events
>>>>>> *qemu: handle libvirtd restart after host usb device unplug
>>>>>> *qemu: handle race on device deletion and usb host device plugging
>>>>>> qemu: hotplug: update device list on device deleted event
>>>>>> *qemu: handle host usb device plug/unplug when libvirtd is down
>>>>>> *qemu: don't mess with non mandatory hostdevs on reattaching
>>>>>> qemu: handle detaching of unplugged hostdev
>>>>>> *conf: parse hostdev missing flag
>>>>>>
>>>>>>docs/formatdomain.html.in | 10 +-
>>>>>>docs/schemas/domaincommon.rng | 5 +
>>>>>>src/conf/domain_conf.c | 62 +++
>>>>>>src/conf/domain_conf.h | 17 +
>>>>>>src/qemu/Makefile.inc.am | 2 +
>>>>>>src/qemu/qemu_conf.h | 3 +
>>>>>>src/qemu/qemu_domain.c | 2 +
>>>>>>src/qemu/qemu_domain.h | 2 +
>>>>>>src/qemu/qemu_driver.c | 404 +++++++++++++++++-
>>>>>>src/qemu/qemu_hotplug.c | 104 ++++-
>>>>>>src/qemu/qemu_hotplug.h | 3 +-
>>>>>>src/qemu/qemu_process.c | 60 +++
>>>>>>src/util/virhostdev.c | 2 +
>>>>>>tests/qemuhotplugtest.c | 2 +-
>>>>>>tests/qemuxml2argvdata/hostdev-usb-replug.xml | 36 ++
>>>>>>.../qemuxml2xmloutdata/hostdev-usb-replug.xml | 40 ++
>>>>>>tests/qemuxml2xmltest.c | 1 +
>>>>>>17 files changed, 733 insertions(+), 22 deletions(-)
>>>>>>create mode 100644 tests/qemuxml2argvdata/hostdev-usb-replug.xml
>>>>>>create mode 100644 tests/qemuxml2xmloutdata/hostdev-usb-replug.xml
>>>>>>
>>>>>>--
>>>>>>2.23.0
>>>>>>
>>>>>>--
>>>>>>libvir-list mailing list
>>>>>>libvir-list(a)redhat.com
>>>>>>https://www.redhat.com/mailman/listinfo/libvir-list
>>>>>>
>>>>>>
>>
5 years, 1 month
[libvirt] [PATCH v3 REBASE 2 00/12] hostdev: handle usb detach/attach on node
by Nikolay Shirokovskiy
Diff to v2[1] version:
- add 'replug' attribute for hostdev element to allow replug semantics
- avoid accuiring domain lock in event loop thread on udev events as
suggested by Peter
- nit picks after review by Daniel Henrique Barboza
* is used to mark patches that were 'Reviewed-by' by Daniel (sometimes
with very minor changes to take into account new replug flag).
Can be applied on:
commit bf0e7bdeeb790bc6ba5732623be0d9ff26a5961a
Author: Peter Krempa <pkrempa(a)redhat.com>
Date: Thu Oct 24 15:50:50 2019 +0200
util: xml: Make virXMLFormatElement void
[1] https://www.redhat.com/archives/libvir-list/2019-September/msg00321.html
Nikolay Shirokovskiy (12):
conf: add replug option for usb hostdev
qemu: track hostdev delete intention
*qemu: support host usb device unplug
*qemu: support usb hostdev plugging back
qemu: handle host usb device add/del udev events
*qemu: handle libvirtd restart after host usb device unplug
*qemu: handle race on device deletion and usb host device plugging
qemu: hotplug: update device list on device deleted event
*qemu: handle host usb device plug/unplug when libvirtd is down
*qemu: don't mess with non mandatory hostdevs on reattaching
qemu: handle detaching of unplugged hostdev
*conf: parse hostdev missing flag
docs/formatdomain.html.in | 10 +-
docs/schemas/domaincommon.rng | 5 +
src/conf/domain_conf.c | 62 +++
src/conf/domain_conf.h | 17 +
src/qemu/Makefile.inc.am | 2 +
src/qemu/qemu_conf.h | 3 +
src/qemu/qemu_domain.c | 2 +
src/qemu/qemu_domain.h | 2 +
src/qemu/qemu_driver.c | 404 +++++++++++++++++-
src/qemu/qemu_hotplug.c | 104 ++++-
src/qemu/qemu_hotplug.h | 3 +-
src/qemu/qemu_process.c | 60 +++
src/util/virhostdev.c | 2 +
tests/qemuhotplugtest.c | 2 +-
tests/qemuxml2argvdata/hostdev-usb-replug.xml | 36 ++
.../qemuxml2xmloutdata/hostdev-usb-replug.xml | 40 ++
tests/qemuxml2xmltest.c | 1 +
17 files changed, 733 insertions(+), 22 deletions(-)
create mode 100644 tests/qemuxml2argvdata/hostdev-usb-replug.xml
create mode 100644 tests/qemuxml2xmloutdata/hostdev-usb-replug.xml
--
2.23.0
5 years, 1 month
[libvirt] [PATCH 0/9] support use of precreated tap devices from unprivileged libvirtd
by Laine Stump
This resolves https://bugzilla.redhat.com/1723367
It has become more popular to run libvirtd in an unprivileged
environment (e.g. inside a container), but until now the only possible
types of network connection for a qemu started by an unprivileged
libvirtd were:
1) a usermode slirp connection
2) a tap device connection to a bridge handled by running
qemu-bridge-helper (a suid-root utility distributed with qemu)
3) a host network card assigned to the guest using VFIO (this requires
special setup by a privileged process though)
This patch series remedies that by making it possible for libvirtd to
use a tap device that has been pre-created (*and* properly setup) by
some other process beforehand.
In order to use this, you must have a standard tap, or macvtap device
that has been set to be owned by the uid that will be running
libvirtd, has its MAC address already set, and has been set online
(IFF_UP). For example, here are the commands to create a standard tap
device named "mytap0", attach it to the host bridge device "br0" and
prepare it for use by a libvirtd that is running as user "laine":
ip tuntap add mode tap user laine group laine name mytap0
ip link set mytap0 up
ip link set mytap0 master br0
(You may want to set a specific MAC address for the tap device, but as
long as it *doesn't* match the MAC address used by the guest emulated
device, it really doesn't matter)
You can now add the following <interface> to a domain definition:
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mytap0' managed='no'/>
</interface>
and start up the guest.
A similar set of commands to create a macvtap device named
"mymacvtap0" with MAC addres 52:54:00:11:11:11 connected to the host
device "en2" would be something like this:
ip link add link en2 name mymacvtap0 address 52:54:00:11:11:11 \
type macvtap mode bridge
ip link set mymacvtap0 up
The XML would be identical, except the name of the device
<interface type='ethernet'>
<model type='virtio'/>
<mac address='52:54:00:11:11:11'/>
<target dev='mymacvtap0' managed='no'/>
</interface>
(Note that in the case of macvtap, the precreated device must *match*
the MAC address of the emulated guest device).
If libvirtd is given a precreated device, that device will *not* be
explicitly deleted when qemu is finished with it - the caller must
take care of that.
Laine Stump (9):
util: new function virNetDevMacVLanIsMacvtap()
util: make a couple virNetDevMacVlan*() functions public
qemu: reorganize qemuInterfaceEthernetConnect()
conf: use virXMLFormatElement for interface <target>
conf: new "managed" attribute for target dev of <interface
type='ethernet'>
qemu: support unmanaged target tap dev for <interface type='ethernet'>
qemu: support unmanaged macvtap devices with <interface
type='ethernet'>
qemu: explicitly delete standard tap devices only on platforms that
require it
docs: update news file
docs/formatdomain.html.in | 48 +++++++---
docs/news.xml | 13 +++
docs/schemas/domaincommon.rng | 5 ++
src/conf/domain_conf.c | 55 +++++++++---
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 3 +
src/qemu/qemu_interface.c | 89 ++++++++++++-------
src/qemu/qemu_process.c | 6 +-
src/util/virnetdev.h | 2 +-
src/util/virnetdevmacvlan.c | 35 ++++++--
src/util/virnetdevmacvlan.h | 12 +++
.../net-eth-unmanaged-tap.args | 32 +++++++
.../net-eth-unmanaged-tap.xml | 35 ++++++++
tests/qemuxml2argvmock.c | 16 +++-
tests/qemuxml2argvtest.c | 1 +
.../net-eth-unmanaged-tap.xml | 40 +++++++++
tests/qemuxml2xmltest.c | 1 +
17 files changed, 329 insertions(+), 65 deletions(-)
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.args
create mode 100644 tests/qemuxml2argvdata/net-eth-unmanaged-tap.xml
create mode 100644 tests/qemuxml2xmloutdata/net-eth-unmanaged-tap.xml
--
2.21.0
5 years, 1 month
