[libvirt] starting LXC container with user namespace with root FS in image (with loop device)
by Dmitry Guryanov
Hello,
I have a container with root fs:
<filesystem type='file' accessmode='passthrough'>
<driver type='loop' format='raw'/>
<source file='/opt/stack/data/nova/instances/x/disk'/>
<target dir='/'/>
</filesystem>
And it seems libvirt tries to mount this FS from a user namespace, which
is not possible:
[root@localhost ~]# virsh -c lxc:/// start instance-0000000aXX
error: Failed to start domain instance-0000000aXX
error: internal error: guest failed to start: Failed to mount device
/dev/loop3 to /var/run/libvirt/lxc/instance-0000000aXX.root: Operation
not permitted
Do you have any ideas, how it's supposed to work?
Here is domain config:
<domain type='lxc'>
<name>instance-0000000aXX</name>
<uuid>c68df696-1499-4cb3-b1fa-e2a370c11382</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>1</vcpu>
<cputune>
<shares>1024</shares>
</cputune>
<resource>
<partition>/machine</partition>
</resource>
<os>
<type arch='x86_64'>exe</type>
<init>/sbin/init</init>
<cmdline>console=tty0 console=ttyS0</cmdline>
</os>
<idmap>
<uid start='0' target='10000' count='1000'/>
<gid start='0' target='10000' count='1000'/>
</idmap>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/libexec/libvirt_lxc</emulator>
<filesystem type='file' accessmode='passthrough'>
<driver type='loop' format='raw'/>
<source file='/opt/stack/data/nova/instances/x/disk'/>
<target dir='/'/>
</filesystem>
<console type='pty'>
<target type='lxc' port='0'/>
</console>
</devices>
</domain>
--
Dmitry Guryanov
10 years, 2 months
[libvirt] [PATCH] qemu: Exit job on error path of qemuDomainSetVcpusFlags()
by Peter Krempa
Commit e105dc981438bc33fa771bd67cece6234dbf6c8d moved some code but
didn't adjust the jump labels so that the job would be terminated.
---
Notes:
I'm already wearing my pink fluffy bunny ears of shame as I've acked that patch.
src/qemu/qemu_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 1bbbe9b..8f0cf2b 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -4716,13 +4716,13 @@ qemuDomainSetVcpusFlags(virDomainPtr dom, unsigned int nvcpus,
if (flags & VIR_DOMAIN_AFFECT_LIVE && !(flags & VIR_DOMAIN_VCPU_GUEST)) {
if (virCgroupNewEmulator(priv->cgroup, false, &cgroup_temp) < 0)
- goto cleanup;
+ goto endjob;
if (!(all_nodes = virNumaGetHostNodeset()))
- goto cleanup;
+ goto endjob;
if (!(all_nodes_str = virBitmapFormat(all_nodes)))
- goto cleanup;
+ goto endjob;
if (virCgroupGetCpusetMems(cgroup_temp, &mem_mask) < 0 ||
virCgroupSetCpusetMems(cgroup_temp, all_nodes_str) < 0)
--
2.2.2
10 years, 2 months
[libvirt] [PATCH 1/2] daemon: Fix segfault by reloading daemon right after start
by Pavel Hrdina
Libvirt could crash with segfault if user issue "service reload" right
after "service start". One possible way to crash libvirt is to run reload
during initialization of QEMU driver.
It could happen when qemu driver will initialize qemu_driver_lock but
don't have a time to set it's "config" and the SIGHUP arrives. The
reload handler tries to get qemu_drv->config during "virStorageAutostart"
and dereference it which ends with segfault.
Let's ignore all reload requests until all drivers are initialized.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1179981
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
daemon/libvirtd.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 86accaa..835e7dc 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -785,6 +785,11 @@ static void daemonReloadHandler(virNetServerPtr srv ATTRIBUTE_UNUSED,
siginfo_t *sig ATTRIBUTE_UNUSED,
void *opaque ATTRIBUTE_UNUSED)
{
+ if (!driversInitialized) {
+ VIR_WARN("Drivers are not initialized, reload ignored");
+ return;
+ }
+
VIR_INFO("Reloading configuration on SIGHUP");
virHookCall(VIR_HOOK_DRIVER_DAEMON, "-",
VIR_HOOK_DAEMON_OP_RELOAD, SIGHUP, "SIGHUP", NULL, NULL);
--
2.0.5
10 years, 2 months
[libvirt] [PATCH] docs: clarify nat range behavior
by Ján Tomko
All the addresses from the range are used, not just those
that are in use on the host.
https://bugzilla.redhat.com/show_bug.cgi?id=1079917
---
docs/formatnetwork.html.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in
index 7cf3f69..6abed8f 100644
--- a/docs/formatnetwork.html.in
+++ b/docs/formatnetwork.html.in
@@ -200,6 +200,8 @@
<p><span class="since">Since 1.0.3</span> it is possible to
specify a public IPv4 address and port range to be used for
the NAT by using the <code><nat></code> subelement.
+ Note that all addresses from the range are used, not just those
+ that are in use on the host.
The address range is set with the <code><address></code>
subelements and <code>start</code> and <code>stop</code>
attributes:
--
2.0.5
10 years, 2 months
[libvirt] [PATCH] libvirt-guests: Allow time sync on guests resume
by Michal Privoznik
Well, imagine domains were running, and as the host went down, they
were managesaved. Later, after some time, the host went up again and
domains got restored. But without correct time. And depending on how
long was the host shut off, it may take some time for ntp to sync the
time too. But hey, wait a minute. We have an API just for that! So:
1) Introduce SYNC_TIME variable in libvirt-guests.sysconf to allow
users control over the new functionality
2) Call 'virsh domtime --sync $dom' in the libvirt-guests script.
Unfortunately, this is all-or-nothing approach (just like anything
else with the script). Domains are required to have configured and
running qemu-ga inside.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tools/libvirt-guests.sh.in | 6 ++++++
tools/libvirt-guests.sysconf | 7 +++++++
2 files changed, 13 insertions(+)
diff --git a/tools/libvirt-guests.sh.in b/tools/libvirt-guests.sh.in
index 1b17bbe..21e39b0 100644
--- a/tools/libvirt-guests.sh.in
+++ b/tools/libvirt-guests.sh.in
@@ -171,7 +171,9 @@ start() {
isfirst=true
bypass=
+ sync_time=false
test "x$BYPASS_CACHE" = x0 || bypass=--bypass-cache
+ test "x$SYNC_TIME" = x0 || sync_time=true
while read uri list; do
configured=false
set -f
@@ -206,6 +208,10 @@ start() {
retval run_virsh "$uri" start $bypass "$name" \
>/dev/null && \
gettext "done"; echo
+ if "$sync_time"; then
+ retval run_virsh "$uri" domtime --sync "$name" \
+ >/dev/null
+ fi
fi
fi
done
diff --git a/tools/libvirt-guests.sysconf b/tools/libvirt-guests.sysconf
index d1f2051..03e732f 100644
--- a/tools/libvirt-guests.sysconf
+++ b/tools/libvirt-guests.sysconf
@@ -39,3 +39,10 @@
# restoring guests, even though this may give slower operation for
# some file systems.
#BYPASS_CACHE=0
+
+# If non-zero, try to sync guest time on a domain resume. Be aware, that
+# this requires guest agent, which, moreover, has to run under supported
+# system. For instance, qemu-ga doesn't support guest time synchronization
+# on Windows guests, but Linux ones. By default, this piece of
+# functionality is turned off.
+#SYNC_TIME=1
--
2.0.5
10 years, 2 months
[libvirt] [PATCH] Fix reporting of i/o errors by iohelper process
by Jason J. Herne
From: "Jason J. Herne" <jjherne(a)us.ibm.com>
libvirt_iohelper is a helper process that is exec'ed and used to handle I/O
during a Qemu managed save operation. Due to a missing call to
virFileWrapperFdClose, all I/O error messages reported by iohelper are lost.
This patch adds a call to virFileWrapperFdClose to the cleanup phase of
qemuDomainSaveMemory.
This patch also modifies virFileWrapperFdClose such that errors are only
reported when the length of the err_msg buffer is > 0. Before now, the
existence of the buffer would trigger error reporting in virFileWrapperFdClose.
Signed-off-by: Jason J. Herne <jjherne(a)us.ibm.com>
---
src/qemu/qemu_driver.c | 1 +
src/util/virfile.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index ecccf6c..8d78805 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3015,6 +3015,7 @@ qemuDomainSaveMemory(virQEMUDriverPtr driver,
cleanup:
VIR_FORCE_CLOSE(fd);
+ virFileWrapperFdClose(wrapperFd);
virFileWrapperFdFree(wrapperFd);
VIR_FREE(xml);
diff --git a/src/util/virfile.c b/src/util/virfile.c
index 463064c..813b4f5 100644
--- a/src/util/virfile.c
+++ b/src/util/virfile.c
@@ -322,7 +322,7 @@ virFileWrapperFdClose(virFileWrapperFdPtr wfd)
return 0;
ret = virCommandWait(wfd->cmd, NULL);
- if (wfd->err_msg)
+ if (wfd->err_msg && strlen(wfd->err_msg))
VIR_WARN("iohelper reports: %s", wfd->err_msg);
return ret;
--
1.8.3.2
10 years, 2 months
[libvirt] libxl and non-absolute paths
by Stefan Bader
Just recently we moved to libvirt 1.2.12 for the next release. Which brought up
a few problems when working with configs which we and Debian used to have.
A mild complaint towards the xml validation: it would be really nice of that
would be a bit more specific about what exactly it complains. It took me a while
to realize that "Extra element os in interleave" was trying to tell me
that the string of the loader element within the os section was not an absolute
path.
The issue here is that with libxl, I think the goal was to rather allow the
library to select the path prefix (like for pygrub where the full path got
removed recently). But now the xml validation disagrees.
This would go for bootloader for xenpv and loader (within os) for xenfv. And for
emulator in the device section. Though for that things are a bit more
complicated. The libxl driver now calls that with the help option and decides
from the output whether this is the "traditional" xen forked qemu or the
upstream qemu binary. Then it selects the device model depending on that outcome.
Not sure whether the libxl driver could query libxl for the path prefix. Right
now the most straight forward way seems to move back to a full path for the
emulator. At least now, by using the standard qemu binary for everything, we got
a predictable path that does not change with Xen versions. So its possible to
force migrate over to put /usr/bin/qemu-system-i386 there.
But for loader and bootloader, do you think it reasonable to change the
templates from absFilePath to filePath?
-Stefan
--- libvirt-1.2.12.orig/docs/schemas/domaincommon.rng 2015-01-23 12:46:24.0000
+++ libvirt-1.2.12/docs/schemas/domaincommon.rng 2015-02-13 10:00:43.1616
@@ -258,7 +258,7 @@
</choice>
</attribute>
</optional>
- <ref name="absFilePath"/>
+ <ref name="filePath"/>
</element>
</optional>
<optional>
@@ -1060,7 +1060,7 @@
<optional>
<element name="bootloader">
<choice>
- <ref name="absFilePath"/>
+ <ref name="filePath"/>
<empty/>
</choice>
</element>
10 years, 2 months
[libvirt] [Patch 0/4] PowerPC fixes for libvirt
by Prerna Saxena
This patch set addresses some miscellaneous fixes for libvirt on PowerPC.
Details:
Patch 1/4 : This adds 'qemu-system-ppc64' as the default emulator for ppc64 & ppc64le guests.
Patch 2/4 : Fixes a small error where not specifying a CPU model leads to a NULL compat specification.
Patch 3/4 : This introduces 'ppc64le' and newer pseries machine types to domain schema.
Patch 4/4 : Forbids floppy devices in domain XML.
Regards,
--
Prerna Saxena
Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
10 years, 2 months
[libvirt] [PATCH 0/2] libxl: fix handling of fd and timer registrations
by Jim Fehlig
This small series fixes some assertions we occasionally see in the
libxl driver when running libvirt-TCK. The assertions were due to
races between destroying per-domain libxl_ctx and receiving fd and
timer callbacks associated with them. The races are masked by
setting DEBUG loglevel in libvirtd.conf, so often missed by
automated test setups that want DEBUG loglevel.
Patch 1 actually fixes the assertions. Patch2 fixes a stupid mistake.
See the commit messages for details.
Jim Fehlig (2):
libxl: fix fd and timer event handling
libxl: Move setup of child processing code to driver initialization
src/libxl/libxl_domain.c | 244 +----------------------------------------------
src/libxl/libxl_driver.c | 212 +++++++++++++++++++++++++++++++++++++++-
2 files changed, 212 insertions(+), 244 deletions(-)
--
1.8.4.5
10 years, 2 months
[libvirt] [PATCH 0/3] Prevent removing a in-used static bridge and destroying a in-used virtual network
by Lin Ma
* Get the live state info of a virtual network through netcf in networkGetXMLDesc.
* Add --system flag for net-dumpxml to show the live state info.
* Check the live state info in net-destroy.
* Add --force flag for net-destroy to forcibly destroy the virtual network.
* Check the transient interfaces info in iface-unbridge.
---
Lin Ma (3):
bridge_driver: Return the live state info of a given virtual network
virsh: prevent destroying a in-used network for net-destroy
virsh: prevent removing a in-used bridge for iface-unbridge
include/libvirt/libvirt-network.h | 1 +
src/Makefile.am | 3 +
src/network/bridge_driver.c | 141 ++++++++++++++++++++++++++++++++++-
src/network/bridge_driver_platform.h | 7 ++
tests/Makefile.am | 4 +
tools/virsh-interface.c | 25 ++++++-
tools/virsh-network.c | 62 ++++++++++++++-
tools/virsh.pod | 8 +-
8 files changed, 241 insertions(+), 10 deletions(-)
--
1.8.4
10 years, 2 months
