[libvirt] [PATCH] qemu: Avoid using ".(null)" in UNIX socket path
by Jiri Denemark
The code which generates paths for UNIX socket blindly used target name
without checking if it was set. Thus for the following device XML
<channel type='unix'>
<source mode='bind'/>
<target type='virtio'/>
</channel>
we would generate "/var/lib/libvirt/qemu/channel/target/NAME.(null)"
path which works but is not really correct. Let's not use the
".target_name" suffix at all if target name is not set.
https://bugzilla.redhat.com/show_bug.cgi?id=1226854
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_domain.c | 20 +++++++++---
.../qemuxml2argv-channel-virtio-unix.args | 19 +++++++++++
.../qemuxml2argv-channel-virtio-unix.xml | 37 ++++++++++++++++++++++
tests/qemuxml2argvtest.c | 5 +++
4 files changed, 77 insertions(+), 4 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.xml
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 6213fd9..404489c 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -1249,11 +1249,23 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev,
dev->data.chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL &&
dev->data.chr->targetType == VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO &&
dev->data.chr->source.type == VIR_DOMAIN_CHR_TYPE_UNIX &&
- !dev->data.chr->source.data.nix.path && cfg) {
- if (virAsprintf(&dev->data.chr->source.data.nix.path, "%s/%s.%s",
- cfg->channelTargetDir,
- def->name, dev->data.chr->target.name) < 0)
+ !dev->data.chr->source.data.nix.path) {
+ if (!cfg) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("cannot generate UNIX socket path"));
goto cleanup;
+ }
+
+ if (dev->data.chr->target.name) {
+ if (virAsprintf(&dev->data.chr->source.data.nix.path, "%s/%s.%s",
+ cfg->channelTargetDir,
+ def->name, dev->data.chr->target.name) < 0)
+ goto cleanup;
+ } else {
+ if (virAsprintf(&dev->data.chr->source.data.nix.path, "%s/%s",
+ cfg->channelTargetDir, def->name) < 0)
+ goto cleanup;
+ }
dev->data.chr->source.data.nix.listen = true;
}
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.args b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.args
new file mode 100644
index 0000000..43a34ce
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.args
@@ -0,0 +1,19 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
+/usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults \
+-chardev socket,id=charmonitor,path=/tmp/test-monitor,server,nowait \
+-mon chardev=charmonitor,id=monitor,mode=readline \
+-no-acpi \
+-boot c \
+-device virtio-serial-pci,id=virtio-serial1,bus=pci.0,addr=0xa \
+-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
+-usb \
+-hda /dev/HostVG/QEMUGuest1 \
+-chardev socket,id=charchannel0,path=\
+/tmp/QEMUGuest1.org.qemu.guest_agent.0,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,\
+name=org.qemu.guest_agent.0 \
+-chardev socket,id=charchannel1,path=/tmp/QEMUGuest1,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1 \
+-chardev socket,id=charchannel2,path=/tmp/QEMUGuest1.ble,server,nowait \
+-device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,\
+name=ble
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.xml b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.xml
new file mode 100644
index 0000000..7fac943
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-unix.xml
@@ -0,0 +1,37 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219136</memory>
+ <vcpu placement='static' cpuset='1-4,8-20,525'>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+ </disk>
+ <controller type='usb' index='0'/>
+ <controller type='ide' index='0'/>
+ <controller type='virtio-serial' index='1'>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
+ </controller>
+ <channel type='unix'>
+ <target type='virtio' name='org.qemu.guest_agent.0'/>
+ </channel>
+ <channel type='unix'>
+ <target type='virtio'/>
+ </channel>
+ <channel type='unix'>
+ <target type='virtio' name='ble'/>
+ </channel>
+ <memballoon model='none'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 4154601..6f8332d 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -519,6 +519,9 @@ mymain(void)
driver.config->spiceTLS = 1;
if (VIR_STRDUP_QUIET(driver.config->spicePassword, "123456") < 0)
return EXIT_FAILURE;
+ VIR_FREE(driver.config->channelTargetDir);
+ if (VIR_STRDUP_QUIET(driver.config->channelTargetDir, "/tmp") < 0)
+ return EXIT_FAILURE;
# define DO_TEST_FULL(name, migrateFrom, migrateFd, flags, ...) \
do { \
@@ -1113,6 +1116,8 @@ mymain(void)
DO_TEST("channel-virtio-default",
QEMU_CAPS_DEVICE, QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG,
QEMU_CAPS_SPICE, QEMU_CAPS_CHARDEV_SPICEVMC);
+ DO_TEST("channel-virtio-unix",
+ QEMU_CAPS_DEVICE, QEMU_CAPS_CHARDEV, QEMU_CAPS_NODEFCONFIG);
DO_TEST("smartcard-host",
QEMU_CAPS_CHARDEV, QEMU_CAPS_DEVICE,
--
2.4.5
9 years, 9 months
[libvirt] [PATCH] qemu: agent: Don't automatically disable CPU0 via guest agent
by Peter Krempa
While CPU0 was made unpluggable in Linux a while ago it's not desirable
to unplug it since some parts of the kernel (suspend-to-ram) still
depend on it.
This patch fixes the vCPU selection code in libvirt so that it will not
be disabled.
---
src/qemu/qemu_agent.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c
index 043695b..7021a7a 100644
--- a/src/qemu/qemu_agent.c
+++ b/src/qemu/qemu_agent.c
@@ -1601,9 +1601,13 @@ qemuAgentUpdateCPUInfo(unsigned int nvcpus,
size_t i;
int nonline = 0;
int nofflinable = 0;
+ ssize_t cpu0 = -1;
/* count the active and offlinable cpus */
for (i = 0; i < ncpuinfo; i++) {
+ if (cpuinfo[i].id == 0)
+ cpu0 = i;
+
if (cpuinfo[i].online)
nonline++;
@@ -1618,6 +1622,15 @@ qemuAgentUpdateCPUInfo(unsigned int nvcpus,
}
}
+ /* CPU0 was made offlinable in linux a while ago, but certain parts (suspend
+ * to ram) of the kernel still don't cope well with that. Make sure that if
+ * all remaining vCPUs are offlinable, vCPU0 will not be selected to be
+ * offlined automatically */
+ if (nofflinable == nonline && cpu0 >= 0 && cpuinfo[cpu0].online) {
+ cpuinfo[cpu0].offlinable = false;
+ nofflinable--;
+ }
+
/* the guest agent reported less cpus than requested */
if (nvcpus > ncpuinfo) {
virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
--
2.4.1
9 years, 9 months
[libvirt] [PATCH 0/4] Some small libxl bug fixes
by Jim Fehlig
While working on a patch to add dom0 support to the libxl driver,
I noticed a few existing bugs which are fixed by this small
series. IMO 1 and 2 are safe even during the freeze as they fix
quite annoying bugs. 3 and 4 are probably safe bug fixes too,
unless I'm confused about the use of
domainObj->{def,newDef,persistentDef}
Jim Fehlig (4):
libxl: don't overwrite domain state from statedir config
libxl: don't remove persistent domain on start failure
libxl: honor domainGetXMLDesc() --inactive flag
libxl: Set def->vcpus after successfully modifying live vcpu count
src/libxl/libxl_driver.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
--
2.3.7
9 years, 9 months
[libvirt] [sandbox v2 00/11] Actually use host-image mounts on /
by Cédric Bosdonnat
Hi all,
In the virt-sandbox documentation we had examples with host-image mounts
targetting /. However the / in the sandbox was still the host one. The
main goal of this patch series is to fix that problem. This will also
be needed to run docker container with libvirt-sandbox.
I also added some configure flags to disable lzma or zlib support at
build time. At least opensuse 13.2 doesn't have static lzma.
Diff to v1:
* Fixed Dan's comments
* Fixed the container case:
* Made init-lxc all-static
* Moved the init copy code to libvirt-sandbox-builder.c
* Use setenv to set the LD_LIBRARY_PATH rather than reset the whole
environment using execve
Cédric Bosdonnat (11):
Allow disabling build with lzma.
Allow disabling zlib support.
Enable strcmp checks in libvirt-sandbox-init-qemu.c
Make init-lxc all static
Copy all needed init programs and all its deps to config subdir
Remove init-common dependency on libvirt-sandbox.so
init-qemu: extract the mounts.cfg ntry mounting code
qemu: use mounts targeting / as root
Add function to check if there is a mount with / target
Don't add sandbox:root device if we have a mount targetting /
container builder: don't expose host rootfs if unneeded
cfg.mk | 2 -
configure.ac | 37 ++++-
libvirt-sandbox/Makefile.am | 45 +++---
.../libvirt-sandbox-builder-container.c | 37 +++--
libvirt-sandbox/libvirt-sandbox-builder-machine.c | 22 +--
libvirt-sandbox/libvirt-sandbox-builder.c | 159 ++++++++++++++++++-
libvirt-sandbox/libvirt-sandbox-builder.h | 2 +
libvirt-sandbox/libvirt-sandbox-config-all.h | 62 ++++++++
libvirt-sandbox/libvirt-sandbox-config-disk.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config-initrd.c | 2 +-
.../libvirt-sandbox-config-interactive.c | 2 +-
.../libvirt-sandbox-config-mount-file.c | 2 +-
.../libvirt-sandbox-config-mount-guest-bind.c | 2 +-
.../libvirt-sandbox-config-mount-host-bind.c | 2 +-
.../libvirt-sandbox-config-mount-host-image.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config-mount-ram.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config-mount.c | 2 +-
.../libvirt-sandbox-config-network-address.c | 2 +-
...rt-sandbox-config-network-filterref-parameter.c | 2 +-
.../libvirt-sandbox-config-network-filterref.c | 2 +-
.../libvirt-sandbox-config-network-route.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config-network.c | 2 +-
.../libvirt-sandbox-config-service-generic.c | 2 +-
.../libvirt-sandbox-config-service-systemd.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config-service.c | 2 +-
libvirt-sandbox/libvirt-sandbox-config.c | 23 ++-
libvirt-sandbox/libvirt-sandbox-config.h | 1 +
libvirt-sandbox/libvirt-sandbox-init-common.c | 5 +-
libvirt-sandbox/libvirt-sandbox-init-lxc.c | 16 +-
libvirt-sandbox/libvirt-sandbox-init-qemu.c | 175 +++++++++++++++++----
libvirt-sandbox/libvirt-sandbox-util.c | 2 +-
libvirt-sandbox/libvirt-sandbox.sym | 1 +
32 files changed, 519 insertions(+), 104 deletions(-)
create mode 100644 libvirt-sandbox/libvirt-sandbox-config-all.h
--
2.1.4
9 years, 9 months
[libvirt] [PATCH] qemu: process: Improve update of maximum baloon state at startup
by Peter Krempa
In commit 641a145d73fdc3dd9350fd57b3d3247abf101c05 I've added code that
resets the ballon memory value to full size prior to resuming the vCPUs
since the size certainly was not reduced at that point.
Since qemuProcess start is used also in code paths with already booted
up guests (migration, save/restore) the assumption is not entirely true
since the guest might already been running before.
This patch adds a function that queries the monitor rather than using
the full size since a balloon event would not be reissued in case we are
recovering a saved migration state.
Additionally the new function is used also when reconnecting to a VM
after libvirtd restart since we might have missed a few ballon events
while libvirtd was not running.
---
src/qemu/qemu_process.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index ba84182..5698404 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -2065,6 +2065,35 @@ qemuProcessReconnectRefreshChannelVirtioState(virQEMUDriverPtr driver,
static int
+qemuProcessRefreshBallonState(virQEMUDriverPtr driver,
+ virDomainObjPtr vm)
+{
+ unsigned long long balloon;
+ int rc;
+
+ /* if no balloning is available, the current size equals to the current
+ * full memory size */
+ if (!vm->def->memballoon ||
+ vm->def->memballoon->model == VIR_DOMAIN_MEMBALLOON_MODEL_NONE) {
+ vm->def->mem.cur_balloon = virDomainDefGetMemoryActual(vm->def);
+ return 0;
+ }
+
+ qemuDomainObjEnterMonitor(driver, vm);
+ rc = qemuMonitorGetBalloonInfo(qemuDomainGetMonitor(vm), &balloon);
+ if (qemuDomainObjExitMonitor(driver, vm) < 0)
+ rc = -1;
+
+ if (rc < 0)
+ return -1;
+
+ vm->def->mem.cur_balloon = balloon;
+
+ return 0;
+}
+
+
+static int
qemuProcessWaitForMonitor(virQEMUDriverPtr driver,
virDomainObjPtr vm,
int asyncJob,
@@ -3779,6 +3808,9 @@ qemuProcessReconnect(void *opaque)
if (qemuProcessReconnectRefreshChannelVirtioState(driver, obj) < 0)
goto error;
+ if (qemuProcessRefreshBallonState(driver, obj) < 0)
+ goto error;
+
if (qemuProcessRecoverJob(driver, obj, conn, &oldjob) < 0)
goto error;
@@ -4922,7 +4954,8 @@ int qemuProcessStart(virConnectPtr conn,
/* Since CPUs were not started yet, the ballon could not return the memory
* to the host and thus cur_balloon needs to be updated so that GetXMLdesc
* and friends return the correct size in case they can't grab the job */
- vm->def->mem.cur_balloon = virDomainDefGetMemoryActual(vm->def);
+ if (qemuProcessRefreshBallonState(driver, vm) < 0)
+ goto cleanup;
VIR_DEBUG("Detecting actual memory size for video device");
if (qemuProcessUpdateVideoRamSize(driver, vm, asyncJob) < 0)
--
2.4.1
9 years, 9 months
[libvirt] [PATCH 0/3] Address a couple of mpath/Multipath storage pool issues
by John Ferlan
My thought was to combine patch 2 and 3 unless it was felt that disallowing
more than one Multipath pool to defined at one time (patch 3) was unnecessary
For patch 1, I did some searching and came across the following to describe
why /dev/mpath is no longer valid:
http://comments.gmane.org/gmane.linux.kernel.device-mapper.devel/13864
I kept /dev/mpath as a valid option only just in case there's some strange
back-compat issue or some platform where /dev/mpath is preferred/used
instead of /dev/mapper.
John Ferlan (3):
mpath: Update path in CheckPool function
docs: Clarify the Multipath target path value usage
mpath: Don't allow more than one mpath pool at a time
docs/formatstorage.html.in | 2 ++
docs/storage.html.in | 3 ++-
src/conf/storage_conf.c | 3 +++
src/storage/storage_backend_mpath.c | 3 ++-
4 files changed, 9 insertions(+), 2 deletions(-)
--
2.1.0
9 years, 9 months
[libvirt] [PATCH 0/2] Domain lifecycle onCrash adjustments
by John Ferlan
First patch uses the right symbols, second patch adds an extra check to
qemu backend for the coredump-destroy action
John Ferlan (2):
Use the correct symbol for 'onCrash'
qemu: Add missing on_crash lifecycle type
src/lxc/lxc_native.c | 2 +-
src/qemu/qemu_command.c | 5 +++--
src/vmx/vmx.c | 2 +-
src/xenconfig/xen_sxpr.c | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
--
2.1.0
9 years, 9 months
[libvirt] [RFC] qemu: Redesigning guest CPU configuration
by Jiri Denemark
Hi all (and sorry for the long email),
The current way QEMU driver handles guest CPU configuration is not
ideal. We detect host CPU capabilities only by querying the CPU and we
don't check with QEMU what features it supports. We don't check QEMU's
definitions of CPU models, which may be different from libvirt's
definitions. All this results in several issues:
- guest CPU may change druing migration, save/restore
- libvirt may ask for a CPU which QEMU cannot provide; the guest will
see a slightly different CPU but libvirt client won't know about it
- libvirt may come up with a CPU that doesn't make sense and which won't
work for a guest (the guest may even crash)
Although usually everything just works, it is very fragile.
Since we want to fix all these issues, we need to:
- guarantee stable guest ABI (a single domain XML should always results
in the same guest ABI). Once a domain is started, its CPU definition
should never change (unless someone changes the XML, of course,
similar to, e.g. PCI addresses). However, there are a few exceptions:
- host-passthrough CPU mode will always result in "-cpu host"
- host-model CPU mode should recompute the CPU model on every start,
but the CPU must not change during migration
- always make sure QEMU provides the CPU we asked for. Starting a domain
should fail in case QEMU cannot provide exactly the CPU we asked for.
- provide usable host-model mode and custom mode with minimum match. We
need to generate CPU configurations that actually work, i.e., we need
to ask QEMU what CPU it can provide on current host rather than
requesting a bunch of features on top of a CPU model which does not
always match the host CPU.
QEMU already provides or will soon provide everything we need to meet
these requirements:
- we can cover every configurable part of a CPU in our cpu_map.xml and
instead of asking QEMU for a specific CPU model we can use "-cpu
custom" with a fully specified CPU
- we can use the additional data about CPU models to choose the right
one for a host CPU
- when starting a domain we can check whether QEMU filtered out any of
the features we asked for and refuse to start the domain
- we can ask QEMU what would "-cpu host" look like and use that for
host-model and minimum match CPUs (it won't work for TCG mode, though,
but we can keep using the current CPUID detection code for TCG)
Once we start maintaining CPU models with all the details, we will
likely meet the same issues QEMU folks meet, i.e., we will need to fix
bugs in existing CPU models. And it's not just about adding removing CPU
features but also fixing other parameters, such as wrong level, etc.
It's clear every change will require a new CPU model to be defined. But
I think we should do it in a way that applications or users should not
need (if they don't want to) to care about it. I'm thinking about doing
something similar to machine types. Each CPU model could be defined in
several versions and a CPU specs without a version would be an alias to
the latest version.
The problem is, we need to maintain backward compatibility and we should
avoid breaking existing domains (shouldn't we?) which just work even
though their guest CPUs do not exactly match the domain XML definitions.
So either we need to define all existing CPU models in all their
variants used for various machine types and have a mapping between
(model without a version, machine type) to a specific version of the
model (which may be quite hard) or we need to be able to distinguish
between an existing domain and a new domain with no CPU model version.
While host-model and host-passthrough CPU modes are easy because they
are designed to change everytime a domain starts (which means we don't
need to be able to distinguish between existing and new domains), custom
CPU mode are tricky. Currently, the only at least a bit reasonable thing
which came to my mind is to have a new CPU mode, but it still seems
awkward so please share your ideas if you have any.
BTW, I don't think we should try to expose every part of the CPU model
definitions in domain XML, they should remain hidden behind the CPU
model name. It would be hard to explain what each of the extra
parameters mean, each model would have to include them anyway since we
can't expect users to provide all the details correctly, and once
visible in domain XML it could encourage users to play with the values.
I'm looking forward to any comments or ideas.
Jirka
9 years, 9 months
[libvirt] [PATCH 0/7] Restore code to allow unpriv_sgio for hostdev SCSI generic
by John Ferlan
https://bugzilla.redhat.com/show_bug.cgi?id=1072736
This series of patches unreverts the functionality from commit id 'ce346623'
which reverted the original functionality.
Since pure revert caused too many conflicts and because the code has
undergone a few changes since the prior reversion, I had to restore
the code by rote method. The reversion includes some refactorings to
make the final check much easier to handle. Of note patch 3 covers much
of what was adjusted in the reverted patch 'qemuCheckSharedDevice'.
Patch 4 expands the driver lock to cover the same space as the
similar disk code - I can take the other as well and shorten the
time the disk code has the lock. Keeping them similar is mostly a
sanity thing.
John Ferlan (7):
qemu: Introduce qemuIsSharedHostdev
qemu: Introduce qemuGetHostdevPath
qemu: Refactor qemuCheckSharedDisk to create virCheckUnprivSGIO
qemu: Refactor qemuAddSharedHostdev and qemuRemoveSharedHostdev
qemu: Extract qemuGetHostdevPath from qemuGetSharedHostdevKey
qemu: Add ability to set sgio values for hostdev
qemu: Add check for unpriv sgio for SCSI generic host device
src/qemu/qemu_conf.c | 205 ++++++++++++++++++++++++++++++++++-----------------
1 file changed, 138 insertions(+), 67 deletions(-)
--
2.1.0
9 years, 9 months
