If a user manually runs libvirtd though, it is sometimes
possible to get into a situation where it is running
system_u:system_r:init_t:s0
The SELinux security driver isn't expecting this and can't
parse the security label since it lacks the ':c0.c1023' part
causing it to complain
internal error Cannot parse sensitivity level in s0
This updates the parser to cope with this, so if no category
is present, libvirtd will hardcode the equivalent of c0.c1023.
Now this won't work if SELinux is in Enforcing mode, but that's
not an issue, because the user can only get into this problem
if in Permissive mode. This means they can now start VMs in
Permissive mode without hitting that parsing error
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Fix memory leak on OOM in virSecuritySELinuxMCSFind
The body of the loop in virSecuritySELinuxMCSFind would
directly 'return NULL' on OOM, instead of jumping to the
cleanup label. This caused a leak of several local vars.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Avoid closing uninitialized FDs when LXC startup fails
If an LXC domain failed to start because of a bogus SELinux
label, virLXCProcessStart would call VIR_CLOSE(0) by mistake.
This is because the code which initializes the member of the
ttyFDs array to -1 got moved too far away from the place where
the array is first allocated.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Prevent streams from becoming libvirtd controlling TTY
When opening a stream to a device which is a TTY, that device
may become the controlling TTY of libvirtd, if libvirtd was
daemonized. This in turn means when the other end of the stream
closes, libvirtd gets SIGHUP, causing it to reload its config.
Prevent this by forcing O_NOCTTY on all streams that are opened
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Guannan Ren [Sat, 9 Mar 2013 14:49:16 +0000 (22:49 +0800)]
util: escapes special characters in VIR_LOG_REGEX
In debug mode, the bug failed to start vm
error: Failed to start domain rhel5u9
error: internal error Out of space while reading console log output:
...
J.B. Joret [Tue, 5 Mar 2013 15:44:22 +0000 (16:44 +0100)]
S390: Add hotplug support for s390 virtio devices
We didn't yet expose the virtio device attach and detach functionality
for s390 domains as the device hotplug was very limited with the old
virtio-s390 bus. With the CCW bus there's full hotplug support for
virtio devices in QEMU, so we are adding this to libvirt too.
Since the virtio hotplug isn't limited to PCI anymore, we change the
function names from xxxPCIyyy to xxxVirtioyyy, where we handle all
three virtio bus types.
Signed-off-by: J.B. Joret <jb@linux.vnet.ibm.com> Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
This commit adds the QEMU driver support for CCW addresses. The
current QEMU only allows virtio devices to be attached to the
CCW bus. We named the new capability indicating that support
QEMU_CAPS_VIRTIO_CCW accordingly.
The fact that CCW devices can only be assigned to domains with a
machine type of s390-ccw-virtio requires a few extra checks for
machine type in qemu_command.c on top of querying
QEMU_CAPS_VIRTIO_{CCW|S390}.
The majority of the new functions deals with CCW address generation
and management.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Add necessary handling code for the new s390 CCW address type to
virDomainDeviceInfo. Further, introduce memory management, XML
parsing, output formatting and range validation for the new
virDomainDeviceCCWAddress type.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
The native bus for s390 I/O is called CCW (channel command word).
As QEMU has added basic support for the CCW bus, i.e. the
ability to assign CCW devnos (bus addresses) to devices.
Domains with the new machine type s390-ccw-virtio can use the
CCW bus. Currently QEMU will only allow to define virtio
devices on the CCW bus.
Here we add the new machine type and the new device address to the
schema definition and add a new paragraph to the domain XML
documentation.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
In some startup failure modes, the fuse thread may get itself
wedged. This will cause the entire libvirt_lxc process to
hang trying to the join the thread. There is no compelling
reason to wait for the thread to exit if the whole process
is exiting, so just daemonize the fuse thread instead.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
A number of symbols are only present when GNUTLS is enabled.
Thus we must use a separate libvirt_gnutls.syms file for them
instead of libvirt_private.syms
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Fix missing error dispatch in virDomainLxcEnterNamespace
The virDomainLxcEnterNamespace method mistakenly uses
virCheckFlags, which returns immediately instead of
virCheckFlagsGoto which jumps to the error cleanup
patch where there is a virDispatchError call
Add a new virDomainLxcEnterSecurityLabel() function as a
counterpart to virDomainLxcEnterNamespaces(), which can
change the current calling process to have a new security
context. This call runs client side, not in libvirtd
so we can't use the security driver infrastructure.
When entering a namespace, the process spawned from virsh
will default to running with the security label of virsh.
The actual desired behaviour is to run with the security
label of the container most of the time. So this changes
virsh lxc-enter-namespace command to invoke the
virDomainLxcEnterSecurityLabel method.
Michal Privoznik [Wed, 13 Mar 2013 10:29:38 +0000 (11:29 +0100)]
qemu_driver: Try KVM_CAP_MAX_VCPUS only if defined
With our recent patch (1715c83b5f) we thrive to get the correct
number of maximal VCPUs. However, we are using a constant from
linux/kvm.h which may be not defined in every distro. Hence, we
should guard usage of the constant with ifdef preprocessor
directive. This was introduced in kernel:
The patch raises the hard limit of VCPU count to 254.
This will allow developers to easily work on scalability
and will allow users to test high VCPU setups easily without
patching the kernel.
To prevent possible issues with current setups, KVM_CAP_NR_VCPUS
now returns the recommended VCPU limit (which is still 64) - this
should be a safe value for everybody, while a new KVM_CAP_MAX_VCPUS
returns the hard limit which is now 254.
Peter Krempa [Tue, 5 Mar 2013 15:17:24 +0000 (16:17 +0100)]
virCaps: conf: start splitting out irrelevat data
The virCaps structure gathered a ton of irrelevant data over time that.
The original reason is that it was propagated to the XML parser
functions.
This patch aims to create a new data structure virDomainXMLConf that
will contain immutable data that are used by the XML parser. This will
allow two things we need:
1) Get rid of the stuff from virCaps
2) Allow us to add callbacks to check and add driver specific stuff
after domain XML is parsed.
This first attempt removes pointers to private data allocation functions
to this new structure and update all callers and function that require
them.
Remove hack using existance of an 'identity' string to disable auth
Currently the server determines whether authentication of clients
is complete, by checking whether an identity is set. This patch
removes that lame hack and replaces it with an explicit method
for changing the client auth code
* daemon/remote.c: Update for new APis
* src/libvirt_private.syms, src/rpc/virnetserverclient.c,
src/rpc/virnetserverclient.h: Remove virNetServerClientGetIdentity
and virNetServerClientSetIdentity, adding a new method
virNetServerClientSetAuth.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add a virThreadCancel function. This functional is inherently
dangerous and not something we want to use in general, but
integration with SELinux requires that we provide this stub.
We leave out any Win32 impl to discourage further use and
because obviously SELinux isn't enabled on Win32
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Jiri Denemark [Tue, 12 Mar 2013 08:10:41 +0000 (09:10 +0100)]
qemu: Avoid NULL dereference in qemuSharedDiskEntryFree
At least one caller may call qemuSharedDiskEntryFree with NULL as the
first argument. Let's make the function similar to other *Free functions
and do nothing in such case.
Jiri Denemark [Mon, 11 Mar 2013 13:42:40 +0000 (14:42 +0100)]
docs: Clarify semantics of sparse storage volumes
Sparse LVM volumes do not behave in the way one would naively expect.
The allocation does not automatically increase (which is different from
how sparse files work).
Peter Krempa [Mon, 11 Mar 2013 13:50:54 +0000 (14:50 +0100)]
qemu: Fix retrieval of maximum number of vCPUs on KVM hosts
The detection of the maximum number of cpus used incorrect ioctl
argument value. This flaw caused that on kvm hosts this returns always
"160" as the maximum. This is just a recommended maximum value. The real
value is higher than that.
This patch tweaks the detection function to behave as described by the
kernel docs:
Ján Tomko [Mon, 11 Mar 2013 12:22:21 +0000 (13:22 +0100)]
virsh: fix snapshot-create with no xmlfile
Properly check the return value of vshCommandOptStringReq for xmlfile:
* error out on incorrect input (--xmlfile '')
* use default XML <domainsnapshot/> with no --xmlfile specified
Guido Günther [Sat, 9 Mar 2013 13:51:25 +0000 (14:51 +0100)]
lxc: Init activeUsbHostdevs
otherwise we crash with
#0 virUSBDeviceListFind (list=0x0, dev=dev@entry=0x8193d70) at util/virusb.c:526
#1 0xb1a4995b in virLXCPrepareHostdevUSBDevices (driver=driver@entry=0x815d9a0, name=0x815dbf8 "debian-700267", list=list@entry=0x81d8f08) at lxc/lxc_hostdev.c:88
#2 0xb1a49fce in virLXCPrepareHostUSBDevices (def=0x8193af8, driver=0x815d9a0) at lxc/lxc_hostdev.c:261
#3 virLXCPrepareHostDevices (driver=driver@entry=0x815d9a0, def=0x8193af8) at lxc/lxc_hostdev.c:328
#4 0xb1a4c5b1 in virLXCProcessStart (conn=0x817d3f8, driver=driver@entry=0x815d9a0, vm=vm@entry=0x8190908, autoDestroy=autoDestroy@entry=false, reason=reason@entry=VIR_DOMAIN_RUNNING_BOOTED)
at lxc/lxc_process.c:1068
#5 0xb1a57e00 in lxcDomainStartWithFlags (dom=dom@entry=0x815e460, flags=flags@entry=0) at lxc/lxc_driver.c:1014
#6 0xb1a57fc3 in lxcDomainStart (dom=0x815e460) at lxc/lxc_driver.c:1046
#7 0xb79c8375 in virDomainCreate (domain=domain@entry=0x815e460) at libvirt.c:8450
#8 0x08078959 in remoteDispatchDomainCreate (args=0x81920a0, rerr=0xb65c21d0, client=0xb0d00490, server=<optimized out>, msg=<optimized out>) at remote_dispatch.h:1066
#9 remoteDispatchDomainCreateHelper (server=0x80c4928, client=0xb0d00490, msg=0xb0d005b0, rerr=0xb65c21d0, args=0x81920a0, ret=0x815d208) at remote_dispatch.h:1044
#10 0xb7a36901 in virNetServerProgramDispatchCall (msg=0xb0d005b0, client=0xb0d00490, server=0x80c4928, prog=0x80c6438) at rpc/virnetserverprogram.c:432
#11 virNetServerProgramDispatch (prog=0x80c6438, server=server@entry=0x80c4928, client=0xb0d00490, msg=0xb0d005b0) at rpc/virnetserverprogram.c:305
#12 0xb7a300a7 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x80c4928) at rpc/virnetserver.c:162
#13 virNetServerHandleJob (jobOpaque=0xb0d00510, opaque=0x80c4928) at rpc/virnetserver.c:183
#14 0xb7924f98 in virThreadPoolWorker (opaque=opaque@entry=0x80a94b0) at util/virthreadpool.c:144
#15 0xb7924515 in virThreadHelper (data=0x80a9440) at util/virthreadpthread.c:161
#16 0xb7887c39 in start_thread (arg=0xb65c2b70) at pthread_create.c:304
#17 0xb77eb78e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
when adding a domain with a usb device. This is Debian bug
bandwidth: Require network QoS if interface uses 'floor'
By current implementation, network inbound is required in order
to use 'floor' for guaranteeing minimal throughput. This is so,
because we want user to tell us the maximal throughput of the
network instead of finding out ourselves (and detect bogus values
in case of virtual interfaces). However, we are nowadays
requiring this only on documentation level. So if user starts a
domain with 'floor' set on one its interfaces, we silently ignore
the setting. We should error out instead.
Guido Günther [Fri, 8 Mar 2013 16:28:37 +0000 (17:28 +0100)]
lxc: include sys/stat.h
This fixes the build on Debian Wheezy which otherwise fails with:
CC libvirt_driver_lxc_impl_la-lxc_process.lo
lxc/lxc_process.c: In function 'virLXCProcessGetNsInode':
lxc/lxc_process.c:648:5: error: implicit declaration of function 'stat' [-Werror=implicit-function-declaration]
lxc/lxc_process.c:648:5: error: nested extern declaration of 'stat' [-Werror=nested-externs]
cc1: all warnings being treated as errors
qemuDomainBlockStatsFlags: Guard disk lookup with a domain job
When there are two concurrent threads, we may dereference a NULL
pointer, even though it has been checked before:
1. Thread1: starts executing qemuDomainBlockStatsFlags() with nparams != 0.
It finds given disk and successfully pass check for disk->info.alias
not being NULL.
2. Thread2: starts executing qemuDomainDetachDeviceFlags() on the very same
disk as Thread1 is working on.
3. Thread1: gets to qemuDomainObjBeginJob() where it sets a job on a
domain.
4. Thread2: also tries to set a job. However, we are not guaranteed which
thread wins. So assume it's Thread2 who can continue.
5. Thread2: does the actual detach and frees disk->info.alias
6. Thread2: quits the job
7. Thread1: now successfully acquires the job, and accesses a NULL pointer.
Guannan Ren [Thu, 7 Mar 2013 16:16:59 +0000 (00:16 +0800)]
apparmor: use AppArmorSetFDLabel for both imageFD and tapFD
Rename AppArmorSetImageFDLabel to AppArmorSetFDLabel which could
be used as a common function for *ALL* fd relabelling in Linux.
In apparmor profile for specific vm with uuid cdbebdfa-1d6d-65c3-be0f-fd74b978a773
Path: /etc/apparmor.d/libvirt/libvirt-cdbebdfa-1d6d-65c3-be0f-fd74b978a773.files
The last line is for the tapfd relabelling.
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
"/var/log/libvirt/**/rhel6qcow2.log" w,
"/var/lib/libvirt/**/rhel6qcow2.monitor" rw,
"/var/run/libvirt/**/rhel6qcow2.pid" rwk,
"/run/libvirt/**/rhel6qcow2.pid" rwk,
"/var/run/libvirt/**/*.tunnelmigrate.dest.rhel6qcow2" rw,
"/run/libvirt/**/*.tunnelmigrate.dest.rhel6qcow2" rw,
"/var/lib/libvirt/images/rhel6u3qcow2.img" rw,
"/dev/tap45" rw,
Add support for disks backed by plain files in LXC
By using a loopback device, disks backed by plain files can
be made available to LXC containers. We make no attempt to
auto-detect format if <driver type="raw"/> is not set,
instead we unconditionally treat that as meaning raw. This
is to avoid the security issues inherent with format
auto-detection
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Convert QEMU driver to use virLogProbablyLogMessage
The current QEMU code for skipping log messages only skips over
'debug' message, switch to virLogProbablyLogMessage to make sure
it skips over all of them
Currently we rely on a VIR_ERROR message being logged by the
virRaiseError function to report LXC startup errors. This gives
the right message, but is rather ugly and can be truncated
if lots of log messages are written. Change the LXC controller
to explicitly print any virErrorPtr message to stderr. Then
change the driver to skip over anything that looks like a log
message.
The result is that this
error: Failed to start domain busy
error: internal error guest failed to start: 2013-03-04 19:46:42.846+0000: 1734: info : libvirt version: 1.0.2
2013-03-04 19:46:42.846+0000: 1734: error : virFileLoopDeviceAssociate:600 : Unable to open /root/disk.raw: No such file or directory
changes to
error: Failed to start domain busy
error: internal error guest failed to start: Unable to open /root/disk.raw: No such file or directory Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Add method for checking if a string is (probably) a log message
When reading log output from QEMU/LXC we need to skip over any
libvirt log messages. Currently the QEMU driver checks for a
fixed string, but this is better done with a regex. Add a method
virLogProbablyLogMessage to do a regex check
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In the LXC container startup code when switching stdio
streams, we call VIR_FORCE_CLOSE on all FDs. This triggers
a huge number of warnings, but we don't see them because
stdio is closed at this point. strace() however shows them
which can confuse people debugging the code. Switch to
VIR_MASS_CLOSE to avoid this
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Fix conditional build of virNetDevSetupControlFull
The virNetDevSetupControlFull function was protected by a
conditional on SIOCBRADDBR, which is bogus since it does
not use that symbol. Update the conditionals around all
callers to do stricter checks to ensure we always build
succesfully
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The RHEL4 vintage header files do not define GET_VLAN_VID_CMD.
Conditionally define it in our source, since the kernel can
raise a runtime error if it isn't supported
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Don't import loop.h unless HAVE_DECL_LO_FLAGS_AUTOCLEAR is defined
The loop.h on RHEL4 is broken and cannot be imported. We already
detect this in configure as a side-effect of looking for whether
LO_FLAGS_AUTOCLEAR is available. We protected the impl with
HAVE_DECL_LO_FLAGS_AUTOCLEAR, but not the header import
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Code that validates the whitelist for the RNG device filename
didn't account for fact that filename may be NULL. This led
to a NULL reference crash. This wasn't caught since the test
suite was not covering this XML syntax
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
John Ferlan [Wed, 6 Mar 2013 04:43:56 +0000 (23:43 -0500)]
Resolve valgrind error
Resolves the following valgrind error from qemuxml2argvtest:
==20393== 5 bytes in 1 blocks are definitely lost in loss record 2 of 60
==20393== at 0x4A0883C: malloc (vg_replace_malloc.c:270)
==20393== by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so)
==20393== by 0x4CB0D97: virVasprintf (stdio2.h:210)
==20393== by 0x4CB0E53: virAsprintf (virutil.c:2017)
==20393== by 0x428DC5: qemuAssignDeviceAliases (qemu_command.c:791)
==20393== by 0x41DF93: testCompareXMLToArgvHelper (qemuxml2argvtest.c:151)
==20393== by 0x41F53F: virtTestRun (testutils.c:157)
==20393== by 0x41DA9B: mymain (qemuxml2argvtest.c:885)
==20393== by 0x41FB7A: virtTestMain (testutils.c:719)
==20393== by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==20393==
From qemu_command.c/line 791:
if (def->rng) {
if (virAsprintf(&def->rng->info.alias, "rng%d", 0) < 0)
goto no_memory;
}
Jiri Denemark [Wed, 6 Mar 2013 11:57:40 +0000 (12:57 +0100)]
storage: Cleanup logical volume creation code
This patch plugs two memory leaks, removes some useless and confusing
constructs and renames renames "cleanup" label as "error" since it is
only used for error path rather then being common for both success and
error paths.
John Ferlan [Thu, 28 Feb 2013 14:48:16 +0000 (09:48 -0500)]
libxl_driver: Resolve Coverity errors
1. The virObjectLock() call was unconditional, but Unlock was conditional
on vm being valid. Removed the check
2. A call to virDomainEventNewFromObj() isn't guaranteed to return an
event - that check needs to be made prior to libxlDomainEventQueue()
of the event. Did not add libxlDriverLock/Unlock around the call since
some callers already have lock taken
3. Need to initialize fd = -1 in libxlDoDomainSave() since we can jump
to cleanup before it's set.
4. Missing break;'s in libxlDomainModifyDeviceFlags() for case
LIBXL_DEVICE_UPDATE. The default: case would report an error
Guannan Ren [Tue, 5 Mar 2013 15:13:21 +0000 (23:13 +0800)]
util: fix a integer boundary error
A value which is equal to a integer maximum such as LLONG_MAX is
a valid integer value.
The patch fix the following error:
1, virsh memtune vm --swap-hard-limit -1
2, virsh start vm
In debug mode, it shows error like:
virScaleInteger:1813 : numerical overflow:\
value too large: 9007199254740991KiB
Peter Krempa [Wed, 20 Feb 2013 15:15:34 +0000 (16:15 +0100)]
conf: Report errors on cputune parameter parsing
This patch adds proper error reporting if parsing of cputune parameters
fails due to incorrect values provided by the user. Previously no errors
were reported in such a case and the failure was silently ignored.
Peter Krempa [Wed, 20 Feb 2013 13:06:52 +0000 (14:06 +0100)]
conf: Make virDomainDeviceInfoIterate usable without os type
Make the iterator function usable in the next patches. Also refactor
some parts to avoid strcmp if not necessary.
This commit tweaks and shadows the change that was done in commit babe7dada0f90bfde74a716e8fc963b049d76f96 and was needed after the
support for multiple console devices was added. Historically the first
<console> element is alias for the <serial> device.
Eric Blake [Mon, 4 Mar 2013 22:42:07 +0000 (15:42 -0700)]
rng: restrict passthrough names to known-good files
There is some controversy[1] on the qemu list on whether qemu should
have ever allowed arbitrary file name passthrough, or whether it
should be restricted to JUST /dev/random and /dev/hwrng. It is
always easier to add support for additional filenames than it is
to remove support for something once released, so this patch
restricts libvirt 1.0.3 (where the virtio-random backend was first
supported) to just the two uncontroversial names, letting us defer
to a later date any decision on whether supporting arbitrary files
makes sense. Additionally, since qemu 1.4 does NOT support
/dev/fdset/nnn fd passthrough for the backend, limiting to just
two known names means that we don't get tempted to try fd
passthrough where it won't work.
John Ferlan [Tue, 26 Feb 2013 14:11:10 +0000 (09:11 -0500)]
hellolibvirt: Adjust code to use new APIs
Change the order of some conditions and use the AllDomains API to get
a list of all the active and defined domains, then use the Active and
Name API's in order to print.
This changes here adjust the output from:
Attempting to connect to hypervisor
Connected to hypervisor at "qemu:///system"
Hypervisor: "QEMU" version: 0.32.656
There are 0 active and 2 inactive domains
Inactive domains:
foo
bar
Disconnected from hypervisor
to
Attempting to connect to hypervisor
Connected to hypervisor at "qemu:///system"
Hypervisor: "QEMU" version: 0.32.656
There are 0 active and 2 inactive domains
foo (non-active)
bar (non-active)
Disconnected from hypervisor
When given a CA cert with basic constraints to set non-critical,
and key usage of 'key signing', this should be rejected. Version
of GNUTLS < 3 do not rejecte it though, so we never noticed the
test case was broken
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Satoru Moriya [Mon, 4 Mar 2013 17:27:45 +0000 (17:27 +0000)]
qemu: fix wrong evaluation in qemuDomainSetMemoryParameters
19c6ad9a (qemu: Refactor qemuDomainSetMemoryParameters) introduced
a new macro, VIR_GET_LIMIT_PARAMETER(PARAM, VALUE). But if statement
in the macro is not correct and so set_XXXX flags are set to false
in the wrong. As a result, libvirt ignores all memtune parameters.
This patch fixes the conditional expression to work correctly.
Guannan Ren [Mon, 4 Mar 2013 12:38:18 +0000 (20:38 +0800)]
util: use string libvirt to prefix error message instead of libvir
BZ:https://bugzilla.redhat.com/show_bug.cgi?id=912021
Without error handler set, virDefaultErrorFunc will be called, the
error message is prefixed with "libvir:". It become a little better
by using prefix "libvirt:" when working with upper application.
For example:
1, stop libvirtd daemon
2, run virt-top.
libvir: XML-RPC error : Failed to connect \
socket to '/var/run/libvirt/libvirt-sock-ro': \
No such file or directory
libvirt: VIR_ERR_SYSTEM_ERROR: VIR_FROM_RPC: \
Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': \
No such file or directory
I just stumbled over that very issue on F18. Doing a little bit
debugging of the shutdown sequence, it turns out that - at least on my
F18 installation - libvirtd is shutdown *after* iscsid, which makes it
impossible for libvirt to perform the logout of the iscsi session properly.
This patch simply adds another startup dependancy on iscsid.service
which in turn delays iscsid shutdown until after libvirtd has stopped.
Having that applied, the system shuts down properly again.
Commit f506a4c1 changed virSetUIDGID() to be a noop
when uid/gid are -1, while it used to be a noop when
they are <= 0.
The changes in this commit broke creating new VMs in GNOME Boxes
as qemuDomainCheckDiskPresence gets called during domain creation/startup,
which in turn calls virFileAccessibleAs which fails after calling
virSetUIDGID(0, 0) (Boxes uses session libvirtd). virSetUIDGID is called with
(0, 0) as these are the default user/group values in virQEMUDriverConfig
for session libvirtd.
This commit changes virQEMUDriverConfigNew to use -1 as the unpriviledged
uid/gid. I've also looked at the various places where cfg->user is used,
and they all seem to handle -1 correctly.
Michal Privoznik [Thu, 28 Feb 2013 14:59:01 +0000 (15:59 +0100)]
virnetdevmacvlan.c: Introduce mutex for macvlan creation
Currently, after we removed the qemu driver lock, it may happen
that two or more threads will start up a machine with macvlan and
race over virNetDevMacVLanCreateWithVPortProfile(). However,
there's a racy section in which we are generating a sequence of
possible device names and detecting if they exits. If we found
one which doesn't we try to create a device with that name.
However, the other thread is doing just the same. Assume it will
succeed and we must therefore fail. If this happens more than 5
times (which in massive parallel startup surely will) we return
-1 without any error reported. This patch is a simple hack to
both of these problems. It introduces a mutex, so only one thread
will enter the section, and if it runs out of possibilities,
error is reported. Moreover, the number of retries is raised to 20.
There is a lock ordering problem in the QEMU close callback
APIs.
When starting a guest we have a lock on the VM. We then
set a autodestroy callback, which acquires a lock on the
close callbacks.
When running auto-destroy, we obtain a lock on the close
callbacks, then run each callbacks - which obtains a lock
on the VM.
This causes deadlock if anyone tries to start a VM, while
autodestroy is taking place.
The fix is to do autodestroy in 2 phases. First obtain
all the callbacks and remove them from the list under
the close callback lock. Then invoke each callback
from outside the close callback lock.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Fix crash in QEMU auto-destroy with transient guests
When the auto-destroy callback runs it is supposed to return
NULL if the virDomainObjPtr is no longer valid. It was not
doing this for transient guests, so we tried to virObjectUnlock
a mutex which had been freed. This often led to a crash.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Jiri Denemark [Thu, 28 Feb 2013 11:48:01 +0000 (12:48 +0100)]
qemu: Make sure qemuProcessStart is run within a job
qemuProcessStart expects to be run with a job already set and every
caller except for qemuMigrationPrepareAny use it correctly. This bug can
be observed in libvirtd logs during incoming migration as
warning : qemuDomainObjEnterMonitorInternal:979 : This thread seems
to be the async job owner; entering monitor without asking for a
nested job is dangerous
Jim Fehlig [Wed, 27 Feb 2013 23:32:35 +0000 (16:32 -0700)]
Fix starting qemu instances when apparmor driver is enabled
With the apparmor security driver enabled, qemu instances fail
to start
# grep ^security_driver /etc/libvirt/qemu.conf
security_driver = "apparmor"
# virsh start test-kvm
error: Failed to start domain test-kvm
error: internal error security label already defined for VM
The model field of virSecurityLabelDef object is always populated
by virDomainDefGetSecurityLabelDef(), so remove the check for a
NULL model when verifying if a label is already defined for the
instance.
Checking for a NULL model and populating it later in
AppArmorGenSecurityLabel() has been left in the code to be
consistent with virSecuritySELinuxGenSecurityLabel().
Michal Privoznik [Mon, 25 Feb 2013 17:52:12 +0000 (18:52 +0100)]
qemu: Don't fail to shutdown domains with unresponsive agent
Currently, qemuDomainShutdownFlags() chooses the agent method of
shutdown whenever the agent is configured. However, this
assumption is not enough as the guest agent may be unresponsive
at the moment. So unless guest agent method has been explicitly
requested, we should fall back to the ACPI method.
The unitialized local variable qemuVersion can cause an random value
to be returned for the hypervisor version, observable with virsh version.
Introduced by commit b46f7f4a0b96c2d2d01d64d960bd7bc90dc16b0c
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
The QEMU driver has a list of devices nodes that are whitelisted
for all guests. The kernel has recently started returning an
error if you try to whitelist a device which does not exist.
This causes a warning in libvirt logs and an audit error for
any missing devices. eg
The code for putting the emulator threads in a separate cgroup
would spam the logs with warnings
2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3
2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4
2013-02-27 16:08:26.732+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6
This is because it has only created child cgroups for 3 of the
controllers, but was trying to move the processes from all the
controllers. The fix is to only try to move threads in the
controllers we actually created. Also remove the warning and
make it return a hard error to avoid such lazy callers in the
future.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virQEMUCloseCallbacksRunOne method was passing a uuid string
to virDomainObjListFindByUUID, when it actually expected to get
a raw uuid buffer. This was not caught by the compiler because
the method was using a 'void *uuid' instead of first casting
it to the expected type.
This regression was accidentally caused by refactoring in
Eric Blake [Wed, 27 Feb 2013 00:43:12 +0000 (17:43 -0700)]
qemu: -numa doesn't (yet) support disjoint range
https://bugzilla.redhat.com/show_bug.cgi?id=896092 mentions that
qemu 1.4 and earlier only accept a simple start-stop range for
the cpu=... argument of -numa. Libvirt would attempt to use
-numa cpu=1,3 for a disjoint range, which did not work as intended.
Upstream qemu will be adding a new syntax for disjoint cpu ranges
in 1.5; but the design for that syntax is still under discussion
at the time of this patch. So for libvirt 1.0.3, it is safest to
just reject attempts to build an invalid qemu command line; in the
future, we can add a capability bit and translate to the final
accepted design for selecting a disjoint cpu range in numa.
projects / people / liuw / libxenctrl-split / libvirt.git / log