[libvirt] [PATCH] util: Fix the build on MinGW because of missing DT_CHR dirent type
by Erik Skultety
Caused by commit 39480969
Signed-off-by: Erik Skultety <eskultet(a)redhat.com>
---
Pushed under the build breaker rule.
src/util/virutil.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/src/util/virutil.c b/src/util/virutil.c
index da12a11e04..279e6aedc0 100644
--- a/src/util/virutil.c
+++ b/src/util/virutil.c
@@ -2172,9 +2172,6 @@ virHostGetDRMRenderNode(void)
return NULL;
while ((dirErr = virDirRead(driDir, &ent, driPath)) > 0) {
- if (ent->d_type != DT_CHR)
- continue;
-
if (STRPREFIX(ent->d_name, "renderD")) {
have_rendernode = true;
break;
--
2.19.2
5 years, 11 months
[libvirt] [PATCH 0/2] syncNicRxFilterMultiMode: Trivial fixes
by Michal Privoznik
Pushed under trivial rule.
Michal Prívozník (2):
syncNicRxFilterMultiMode: Check for helper's retval properly
syncNicRxFilterMultiMode: Fix indentation
src/qemu/qemu_driver.c | 80 +++++++++++++++++++++---------------------
1 file changed, 40 insertions(+), 40 deletions(-)
--
2.19.2
5 years, 11 months
Re: [libvirt] [PATCH] qemu: Qemu process unexpectedly killed in repeated reboot
by Wangjing (King)
On 11/30/18 9:53 AM, Wang King wrote:
>> The issue occurs when I make repeated calls to virDomainReboot with
>> VIR_DOMAIN_REBOOT_DEFAULT flag. In the first call to reboot domain,
>> the qemu driver chose ACPI path, and set priv->fakeReboot to true.
>> Then in a second call, qemu driver chose agent to reboot which set
>> fakeReboot to false. But because the guest already responded to ACPI
>> shut down, libvirtd daemon will process a SHUTDOWN event in
>> qemuProcessShutdownOrReboot and checks priv->fakeReboot. Since the
>> fakeReboot flag is now false, qemu process is unexpectedly killed.
>>
>
>This sounds fishy. Looking at the code libvirt decides whether to use agent or ACPI based on:
>
>a) flags (but since you're passing 0 this is out of the picture),
>b) guest agent being available,
>
>This means that agent must have connected between two virDomainReboot() calls. Otherwise libvirt would make the same choice.
>
>> I have no idea how to fix it.
>
>Well, the qemuDomainSetFakeReboot(false) call was added in b0c144c5792 which points to:
>
> https://www.redhat.com/archives/libvir-list/2015-April/msg00732.html
>
>I think the patch proposed there is actually right and not the one that was merged.
>
>Michal
The problem:
Consider this scenario: firstly, call virDomainReboot() with mode ACPI to a domain, then immediately call virDomainReboot() again with mode “agent”. Supposedly, this sequence will reboot the domain (hereinafter referred to as DOM1). Instead, however, the current version of libvirt code will *KILL* the QEMU process associated with the domain.
How to reproduce this problem:
Simply make a ACPI-mode reboot call to the domain, and immediately make an agent-mode reboot call. You will see that the domain is killed straight away.
Root cause:
The unexpected SIGKILL comes from Libvirt seeing fakeReboot flag set to *FALSE* when it received an SHUTDOWN event as a result of calling ACPI virDomainReboot(). This happens when DOM1 is already rebooting, yet its guest agent is still available, thus the second agent-mode virDomainReboot() was able to pass the check and set fakeReboot flag to *FALSE* (its “guest-shutdown” command is also sent, which is out of the scope of this email). Finally, DOM1 shut down as part of the reboot process, its QEMU process sent SHUTDOWN event to Libvirt. Libvirt checked fakeReboot flag and saw it being *FALSE*, forcefully kills the QEMU process as a result.
Analysis:
Say that we make two calls to shutdown/reboot DOM1. DOM1 will eventually respond to only one of the two calls. For another call, only two scenarios happen: DOM1 accepts the second call but do not execute it (meaning only fakeReboot flag is modified on Libvirt side), or DOM1 accepts the second call and overrides the first one. In the second scenario, it is the same situation as first scenario but reversed (DOM1 responds to first call and sets flag with second call vs DOM1 responds to second call and sets flag with first call). Therefore, we hereby simplify the problem to that DOM1 always responds to first call, and the second call is also accepted, but it only serves to change the fakeReboot flag. As you will see, there is what we expect to happen versus what actually happens. The questionable result is marked with tilde(~) and the faulted result is marked with emphasis(*).
If you see the chart below, you will see that how the domain should react to shutdown/reboot calls in different order:
-----------------------------------------------------------------------------------------------------------
|First Command |Second Command(set flags only) |Expected Result |Actual Result |After Fix |
-----------------------------------------------------------------------------------------------------------
|ACPI SHUTDOWN |ACPI SHUTDOWN |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|ACPI REBOOT |ACPI SHUTDOWN |REBOOT |~SHUTDOWN~ |~SHUTDOWN~ |
|AGENT SHUTDOWN |ACPI SHUTDOWN |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|AGENT REBOOT |ACPI SHUTDOWN |REBOOT |REBOOT |REBOOT |
|ACPI SHUTDOWN |ACPI REBOOT |SHUTDOWN |~REBOOT~ |~REBOOT~ |
|ACPI REBOOT |ACPI REBOOT |REBOOT |REBOOT |REBOOT |
|AGENT SHUTDOWN |ACPI REBOOT |SHUTDOWN |~REBOOT~ |~REBOOT~ |
|AGENT REBOOT |ACPI REBOOT |REBOOT |REBOOT |REBOOT |
|ACPI SHUTDOWN |AGENT SHUTDOWN |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|ACPI REBOOT |AGENT SHUTDOWN |REBOOT |~SHUTDOWN~ |~SHUTDOWN~ |
|AGENT SHUTDOWN |AGENT SHUTDOWN |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|AGENT REBOOT |AGENT SHUTDOWN |REBOOT |REBOOT |REBOOT |
|ACPI SHUTDOWN |AGENT REBOOT |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|ACPI REBOOT |AGENT REBOOT |REBOOT |**SHUTDOWN** |**REBOOT** |
|AGENT SHUTDOWN |AGENT REBOOT |SHUTDOWN |SHUTDOWN |SHUTDOWN |
|AGENT REBOOT |AGENT REBOOT |REBOOT |REBOOT |REBOOT |
----------------------------------------------------------------------------------------------------------
As you can see, when DOM1 reboots with ACPI and immediately receives agent-mode reboot. It will *SHUTDOWN* instead. (Certainly, there are questionable results in other combos, but we think they cause less confusions in real-life situations so we are not discussing them here)
Fix:
The fix is to revert the changes added by b0c144c5792 commit, which introduced setting fakeReboot to False in agent-mode reboot. This should, at least, avoid killing QEMU process during successive reboot calls. Nonetheless, shutdown/reboot process still needs some optimizations to be done. I will leave it to the analysis above. What do you think about this? Should we revert the commit first or find an all-fix solution to this problem?
5 years, 11 months
[libvirt] Release of libvirt-4.10.0
by Daniel Veillard
As planned I tagged the release in git earlier today and pushed signed
tarball and rpms to the usual place:
ftp://libvirt.org/libvirt/
I also pushed the python bindings at
ftp://libvirt.org/libvirt/python
This release seems to be very heavy on new features, but under the hood
there is as usuall a number of bug fixes and refactoring patches:
New features:
- qemu: Add Hyper-V PV IPI and Enlightened VMCS support
The QEMU driver now has support for Hyper-V PV IPI and Enlightened VMCS
for Windows and Hyper-V guests.
- qemu: Added support for PCI devices on S390
PCI addresses can now include the new zpci element which contains uid
(user-defined identifier) and fid (PCI function identifier) attributes
and makes the corresponding devices usable by S390 guests.
- Support changing IOThread polling parameters for a live guest
Introduced virDomainSetIOThreadParams which allows dynamically setting
the IOThread polling parameters used by QEMU to manage the thread
polling interval and the algorithm for growth or shrink of the polling
time. The values only affect a running guest with IOThreads. The
guest's IOThread polling values can be viewed via the domain
statistics.
- Xen: Add support for PVH
The libxl driver now supports Xen's PVH virtual machine type. PVH
machines are enabled with the new "xenpvh" OS type, e.g.
<os><type>xenpvh</type></os>
- qemu: Added support for CMT (Cache Monitoring Technology)
Introduced cache monitoring using the monitor element in cachetune for
vCPU threads. Added interfaces to get and display the cache utilization
statistics through the command 'virsh domstats' via the
virConnectGetAllDomainStats API.
- qemu: Add support for nested HV for pSeries guests
Nested HV support makes it possible to run nested (L2) guests with
minimal performance penalty when compared to regular (L1) guests on
ppc64 hardware.
Bug fixes:
- Xen: Handle soft reset shutdown event
The pvops Linux kernel uses soft reset to handle the crash machine
operation. The libxl driver now supports the soft reset shutdown event,
allowing proper crash handling of pvops-based HVM domains.
Thanks everybody for your contribution toward this release,
be it with ideas, bug reports, patches reviews, docs, localization...
Remember, next release should be around mid-January, 5.0.0,
in the meantime enjoy the release and end of years vacations you may have !
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, 11 months
[libvirt] [PATCH 0/7] Restructure firewall rules for virtual networks into private chains
by Daniel P. Berrangé
The virtual networks in NAT mode are supposed to only allow outbound
network access for guests. Unfortunately due to ordering of the firewall
rules libvirt creates, when you have multiple virtual networks, guests
on the more recently created virtual networks can connect to guests on
old virtual networks.
This was reported way back in 2008 but we always thought the fix would
be very complicated to deal with, so we've been putting it off forever.
In parallel with this there's also been a long standing desire since
2009 to move our firewall rules out of the builtin chains, to libvirt
private chains. This is to make it easier for admins to use hook scripts
to setup rules in the builtin chains that take priority over rules
libvirt creates.
In implementing the changes to use private chains, I suddenly realized
that fixing the network to network traffic blocking problem was trivial
if I grouped the forwarding rules into three distinct sets.
So this series finally fixes an annoying 10 year old bug, and implements
a 9 year old RFE.
It may take us a while, but we'll get to your bugs eventually ;-)
Daniel P. Berrangé (7):
util: refactor iptables APIs to share more code
util: add iptables API for creating base chains
util: prepare iptables for putting rules into private chains
network: setup default iptables chains
util: switch over to creating rules in private chains
tests: remove duplicated test case in networkxml2firewalltest
tests: fix dry run handling in network firewall test
src/libvirt_private.syms | 1 +
src/network/bridge_driver_linux.c | 3 +
src/util/viriptables.c | 317 ++++++++++++++----
src/util/viriptables.h | 2 +
.../nat-default-linux.args | 150 ++++++++-
.../nat-ipv6-linux.args | 166 +++++++--
.../nat-many-ips-linux.args | 178 ++++++++--
.../nat-no-dhcp-linux.args | 164 +++++++--
.../nat-tftp-linux.args | 152 ++++++++-
.../route-default-linux.args | 140 +++++++-
tests/networkxml2firewalltest.c | 17 +-
11 files changed, 1107 insertions(+), 183 deletions(-)
--
2.19.1
5 years, 11 months
[libvirt] [PATCH v3 00/11] Autoselect a DRM node for egl-headless add it to cmdline
by Erik Skultety
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628892.
The problem is that we didn't put the DRI device into the namespace for QEMU to
access, but that was only a part of the issue. The other part of the issue is
that QEMU doesn't support specifying 'rendernode' for egl-headless yet (patches
are already in upstream) Instead, QEMU's been autoselecting the DRI device on
its own. There's no compelling reason for libvirt not doing that instead and
thus prevent any permission-related issues.
Since v1:
- updated capabilities to 3.1.0-rc2 containing the necessary QEMU patches
- provided more test cases as requested
- added a new XML sub-element <gl> for egl-headless graphics type
Since v2:
- The cmdline code wouldn't play nicely with old QEMU where I'd pick a
rendernode automatically and then fail if we didn't have the corresponding
capability, so this was fixed for v3
- v2 converted some tests to CAPS_LATEST only which would also be wrong because
QEMU can still pick a DRM node so that's a valid use case (not a practical one
though)
- the 3.1.0 capabilities patch was merged separately
Erik Skultety (11):
util: Introduce virHostGetDRMRenderNode helper
conf: Introduce virDomainGraphics-related helpers
qemu: process: spice: Pick the first available DRM render node
qemu: command: Introduce qemuBuildGraphicsEGLHeadlessCommandLine
helper
qemu: caps: Introduce QEMU_EGL_HEADLESS_RENDERNODE capability
conf: gfx: Add egl-headless as a member to virDomainGraphicsDef struct
conf: gfx: egl-headless: Introduce a new <gl> subelement
qemu: domain: egl-headless: Add the DRI device into the namespace
qemu: cgroup: gfx: egl-headless: Add the DRI device into the cgroup
list
security: dac: gfx: egl-headless: Relabel the DRI device
qemu: command: gfx: egl-headless: Add 'rendernode' option to the
cmdline
docs/formatdomain.html.in | 11 ++-
docs/schemas/domaincommon.rng | 17 +++-
src/conf/domain_conf.c | 84 +++++++++++++++++++
src/conf/domain_conf.h | 12 +++
src/libvirt_private.syms | 4 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_cgroup.c | 10 +--
src/qemu/qemu_command.c | 42 +++++++++-
src/qemu/qemu_domain.c | 9 +-
src/qemu/qemu_process.c | 32 ++++++-
src/security/security_dac.c | 15 ++--
src/util/virutil.c | 53 ++++++++++++
src/util/virutil.h | 2 +
.../caps_3.1.0.x86_64.xml | 1 +
...egl-headless-rendernode.x86_64-latest.args | 31 +++++++
.../graphics-egl-headless-rendernode.xml | 33 ++++++++
.../graphics-egl-headless.x86_64-latest.args | 31 +++++++
.../graphics-spice-gl-no-rendernode.args | 25 ++++++
.../graphics-spice-gl-no-rendernode.xml | 24 ++++++
...play-spice-egl-headless.x86_64-latest.args | 2 +-
...isplay-vnc-egl-headless.x86_64-latest.args | 2 +-
tests/qemuxml2argvmock.c | 9 ++
tests/qemuxml2argvtest.c | 2 +
.../graphics-egl-headless-rendernode.xml | 41 +++++++++
tests/qemuxml2xmltest.c | 2 +
26 files changed, 464 insertions(+), 33 deletions(-)
create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless-rendernode.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless-rendernode.xml
create mode 100644 tests/qemuxml2argvdata/graphics-egl-headless.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/graphics-spice-gl-no-rendernode.args
create mode 100644 tests/qemuxml2argvdata/graphics-spice-gl-no-rendernode.xml
create mode 100644 tests/qemuxml2xmloutdata/graphics-egl-headless-rendernode.xml
--
2.19.1
5 years, 11 months
[libvirt] [PATCH 0/2] qemu: arm guest on x86
by infos＠nafets.de
From: Stefan Schallenberg <nafets227(a)users.noreply.github.com>
*** BLURB HERE ***
Stefan Schallenberg (2):
Add armv6l Support as guest
qemu: Add Default PCI Device for arm guests
docs/news.xml | 9 +++++
docs/schemas/basictypes.rng | 1 +
src/qemu/qemu_capabilities.c | 5 ++-
src/qemu/qemu_command.c | 4 +-
src/qemu/qemu_domain.c | 20 ++++++++--
src/qemu/qemu_domain_address.c | 6 ++-
tests/capabilityschemadata/caps-qemu-kvm.xml | 10 +++++
tests/testutilsqemu.c | 40 +++++++++++++++++++-
8 files changed, 84 insertions(+), 11 deletions(-)
--
2.19.2
5 years, 11 months
[libvirt] [PATCH v2] qemu: handle multicast overflow on macvtap NIC_RX_FILTER_CHANGED
by Jason Baron
Guest network devices can set 'overflow' when there are a number of multicast
ips configured. For virtio_net, the limit is only 64. In this case, the list
of mac addresses is empty and the 'overflow' condition is set. Thus, the guest
will currently receive no multicast traffic in this state.
When 'overflow' is set in the guest, let's turn this into ALLMULTI on the host.
Signed-off-by: Jason Baron <jbaron(a)akamai.com>
---
v1->v2:
1. check for < 0 in virNetDevSetRcvAllMulti() (Michal Privoznik)
2. restrict overflow check to VIR_NETDEV_RX_FILTER_MODE_NORMAL mode as to
avoid unnecessarily calling rx filter updates for other modes
3. update virNetDevSetRcvAllMulti() call to use guestFilter->multicast.overflow
directly (Michal Privoznik)
src/qemu/qemu_driver.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 7fb9102..f4bbfea 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4443,11 +4443,12 @@ static void
syncNicRxFilterMultiMode(char *ifname, virNetDevRxFilterPtr guestFilter,
virNetDevRxFilterPtr hostFilter)
{
- if (hostFilter->multicast.mode != guestFilter->multicast.mode) {
+ if (hostFilter->multicast.mode != guestFilter->multicast.mode ||
+ (guestFilter->multicast.overflow &&
+ guestFilter->multicast.mode == VIR_NETDEV_RX_FILTER_MODE_NORMAL)) {
switch (guestFilter->multicast.mode) {
case VIR_NETDEV_RX_FILTER_MODE_ALL:
if (virNetDevSetRcvAllMulti(ifname, true)) {
-
VIR_WARN("Couldn't set allmulticast flag to 'on' for "
"device %s while responding to "
"NIC_RX_FILTER_CHANGED", ifname);
@@ -4455,17 +4456,24 @@ syncNicRxFilterMultiMode(char *ifname, virNetDevRxFilterPtr guestFilter,
break;
case VIR_NETDEV_RX_FILTER_MODE_NORMAL:
- if (virNetDevSetRcvMulti(ifname, true)) {
+ if (guestFilter->multicast.overflow &&
+ (hostFilter->multicast.mode == VIR_NETDEV_RX_FILTER_MODE_ALL)) {
+ break;
+ }
+ if (virNetDevSetRcvMulti(ifname, true)) {
VIR_WARN("Couldn't set multicast flag to 'on' for "
"device %s while responding to "
"NIC_RX_FILTER_CHANGED", ifname);
}
- if (virNetDevSetRcvAllMulti(ifname, false)) {
- VIR_WARN("Couldn't set allmulticast flag to 'off' for "
- "device %s while responding to "
- "NIC_RX_FILTER_CHANGED", ifname);
+ if (virNetDevSetRcvAllMulti(ifname,
+ guestFilter->multicast.overflow) < 0) {
+ VIR_WARN("Couldn't set allmulticast flag to '%s' for "
+ "device %s while responding to "
+ "NIC_RX_FILTER_CHANGED",
+ virTristateSwitchTypeToString(virTristateSwitchFromBool(guestFilter->multicast.overflow)),
+ ifname);
}
break;
--
2.7.4
5 years, 11 months
[libvirt] [PATCH] news: Fix version number
by Andrea Bolognani
The schema expects it to match the pattern
v[0-9]+\.[0-9]+\.[0-9]+
which "5.0.0" clearly doesn't, causing the build to fail.
Reported-by: Peter Krempa <pkrempa(a)redhat.com>
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
The Fabulous Princess Crown of Shame has been deployed.
docs/news.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/news.xml b/docs/news.xml
index 4472936b31..3c63d46012 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -33,7 +33,7 @@
-->
<libvirt>
- <release version="5.0.0" date="unreleased">
+ <release version="v5.0.0" date="unreleased">
<section title="New features">
</section>
<section title="Improvements">
--
2.19.2
5 years, 11 months
