- 04 3月, 2013 1 次提交
-
-
由 Christophe Fergeau 提交于
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.
-
- 01 3月, 2013 7 次提交
-
-
由 Michal Privoznik 提交于
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.
-
由 Daniel P. Berrange 提交于
This reverts the hack done in commit 568a6cda Author: Jiri Denemark <jdenemar@redhat.com> Date: Fri Feb 15 15:11:47 2013 +0100 qemu: Avoid deadlock in autodestroy since we now have a fix which avoids the deadlock scenario entirely
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Jiri Denemark 提交于
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 提交于
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().
-
由 Serge Hallyn 提交于
As pointed out in https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1034661 The sentence "The function of PCI device addresses must less than 8" does not quite make sense. Update that to read "The function of PCI device addresses must be less than 8" Signed-off-by: NSerge Hallyn <serge.hallyn@ubuntu.com>
-
- 28 2月, 2013 8 次提交
-
-
由 Michal Privoznik 提交于
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.
-
由 Viktor Mihajlovski 提交于
The unitialized local variable qemuVersion can cause an random value to be returned for the hypervisor version, observable with virsh version. Introduced by commit b46f7f4aSigned-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Paolo Bonzini 提交于
disk->src is still used for disks->hosts->name, do not free it. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
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 2013-02-27 16:08:26.515+0000: 29625: warning : virDomainAuditCgroup:451 : success=no virt=kvm resrc=cgroup reason=allow vm="vm031714" uuid=9d8f1de0-44f4-a0b1-7d50-e41ee6cd897b cgroup="/sys/fs/cgroup/devices/libvirt/qemu/vm031714/" class=path path=/dev/kqemu rdev=? acl=rw Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
s/VIR_QEMU_PROCESS_START_AUTODESROY/VIR_QEMU_PROCESS_START_AUTODESTROY/ Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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 commit 568a6cda Author: Jiri Denemark <jdenemar@redhat.com> Date: Fri Feb 15 15:11:47 2013 +0100 qemu: Avoid deadlock in autodestroy Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Eric Blake 提交于
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. * src/qemu/qemu_command.c (qemuBuildNumaArgStr): Reject disjoint ranges.
-
- 27 2月, 2013 8 次提交
-
-
由 Laine Stump 提交于
This reverts commit 383ebc46. We decided the xml for this feature needed more thought to make sure we are doing it the best way, in particular wrt option values that have multiple items.
-
由 Peter Krempa 提交于
To avoid confusion about usage of this function explicitly document that this function returns copy of the attribute string.
-
由 Michal Privoznik 提交于
These two flags in fact are mutually exclusive. Requesting them both doesn't make any sense regardless of hypervisor driver. Hence, we have to make it within libvirt.c file instead of fixing it in each driver.
-
由 Eric Blake 提交于
Eugene Marcotte reported that if gcrypt-devel (a prereq of gnutls-devel) is not present, then compilation fails due to an unconditional use of <gcrypt.h>. * src/libvirt.c (includes): Properly guard use of gcrypt.h.
-
由 Eric Blake 提交于
This reverts commit 0bbbd42c. The design for this feature is not complete, and may change the name of the 'schid' attribute. Revert requested by Viktor Mihajlovski.
-
由 Doug Goldstein 提交于
This fixes a potential NULL deref identified by John Ferlan <jferlan@redhat.com> if scandir() didn't return an expected value.
-
由 Daniel P. Berrange 提交于
The parallels storage driver declared some loop variables inside the for(;;). This is not allowed by libvirt coding standards Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
This change tried to fix a crash with changing CDROM media but failed to actually do so commit d0172d2b Author: Osier Yang <jyang@redhat.com> Date: Tue Feb 19 20:27:45 2013 +0800 qemu: Remove the shared disk entry if the operation is ejecting or updating It was still accessing disk->src, when the entire 'disk' object has been free'd already. Even if it weren't free'd, accessing the 'src' value of virDomainDiskDef is not allowed without first validating disk->type is file or block. Just remove the broken code entirely. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 26 2月, 2013 7 次提交
-
-
由 Ján Tomko 提交于
VIR_ERR_NO_CONNECT already contains "no connection driver available". This patch changes: no connection driver available for No connection for URI hello to: no connection driver available for hello Bug: https://bugzilla.redhat.com/show_bug.cgi?id=851413
-
由 Paolo Bonzini 提交于
Currently we call virSetDeviceUnprivSGIO with val == 0 if a block device has an sgio attribute. But for sgio='filtered', we know that a kernel with no unpriv_sgio support will always behave as the user wanted. In this case, there is no need to call the function and report a (bogus) error. Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Eric Blake 提交于
If virCondInit fails (okay, so that's unlikely), then we end up attempting a virObjectUnlock() on the cleanup path, even though we don't hold a lock. This is not guaranteed to be safe. While at it, I noticed a couple places where we were referencing mon->fd outside locks. * src/qemu/qemu_monitor.c (qemuMonitorOpenInternal): Minimize lock duration. mon->watch doesn't need clean up on error. (qemuMonitorGetBlockExtent, qemuMonitorBlockResize): Don't dereference fd outside of lock.
-
由 Eric Blake 提交于
I built without yajl support, and noticed a strange failure message in qemumonitorjsontest: 2013-02-22 16:12:37.503+0000: 19812: error : virJSONValueToString:1119 : internal error No JSON parser implementation is available 2013-02-22 16:12:37.503+0000: 19812: error : qemuMonitorJSONCommandWithFd:253 : out of memory While a later patch will fix the test to skip when json is not present, this patch avoids overriding the more useful error message from virJSONValueToString returning NULL. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCommandWithFd): Don't override message. (qemuMonitorJSONCheckError): Don't print NULL. * src/qemu/qemu_agent.c (qemuAgentCommand): Don't override message. (qemuAgentCheckError): Don't print NULL. (qemuAgentArbitraryCommand): Properly fail on OOM.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
The new TypedParam helper APIs allow to simplify this function significantly. This patch integrates the fix in 75e5bec9 by correctly ordering the setting functions instead of reordering the parameters.
-
由 Doug Goldstein 提交于
The bridge device was showing the vnet devices created for the domains as connected to the bridge. libvirt should only show host devices when trying to get the interface definition rather than the domain devices as well.
-
- 25 2月, 2013 9 次提交
-
-
由 Philipp Hahn 提交于
uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. Explicitly cast the magic -1 to the appropriate type. Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Philipp Hahn 提交于
uid_t and gid_t are opaque types, ranging from s32 to u32 to u64. Explicitly cast them to unsigned int for printing. Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Philipp Hahn 提交于
The uid_t|gid_t values are explicitly casted to "unsigned long", but the printf() still used "%d", which is for signed values. Change the format to "%u". Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Peter Krempa 提交于
This patch adds a new capability bit QEMU_CAPS_OBJECT_RNG_EGD and code to support the egd backend for the VirtIO RNG device. The device is added by 3 qemu command line options: -chardev socket,id=charrng0,host=1.2.3.4,port=1234 (communication backend) -object rng-egd,chardev=charrng0,id=rng0 (RNG protocol client) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (the RNG device)
-
由 Peter Krempa 提交于
This patch implements support for the virtio-rng-pci device and the rng-random backend in qemu. Two capabilities bits are added to track support for those: QEMU_CAPS_DEVICE_VIRTIO_RNG - for the device support and QEMU_CAPS_OBJECT_RNG_RANDOM - for the backend support. qemu is invoked with these additional parameters if the device is enabled: -object rng-random,id=rng0,filename=/test/phile (to add the backend) -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x4 (to add the device)
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
This patch adds basic configuration support for the RNG device supporting the virtio model with the "random" and "egd" backend types as described in the schema in the previous patch.
-
由 Peter Krempa 提交于
This patch adds a fake switch statement to force the compiler to warn after a new device type was added. This should remind the contributor to add the new device also to this iterator function.
-
由 Gene Czarcinski 提交于
Originally, only a host name was used to associate a DHCPv6 request with a specific IPv6 address. Further testing demonstrates that this is an unreliable method and, instead, a client-id or DUID needs to be used. According to DHCPv6 standards, this id can be a duid-LLT, duid-LL, or duid-UUID even though dnsmasq will accept almost any text string. Although validity checking of a specified string makes sure it is hexadecimal notation with bytes separated by colons, there is no rigorous check to make sure it meets the standard. Documentation and schemas have been updated. Signed-off-by: NGene Czarcinski <gene@czarc.net> Signed-off-by: NLaine Stump <laine@laine.org>
-