- 15 12月, 2013 3 次提交
-
-
由 Christophe Fergeau 提交于
The array of sasl_callback_t callbacks which is passed to sasl_client_new() must be kept alive as long as the created sasl_conn_t object is alive as cyrus-sasl uses this structure internally for things like logging, so the memory used for callbacks must only be freed after sasl_dispose() has been called. During testing of successful SASL logins with virsh -c qemu+tls:///system list --all I've been getting invalid read reports from valgrind ==9237== Invalid read of size 8 ==9237== at 0x6E93B6F: _sasl_getcallback (common.c:1745) ==9237== by 0x6E95430: _sasl_log (common.c:1850) ==9237== by 0x16593D87: digestmd5_client_mech_dispose (digestmd5.c:4580) ==9237== by 0x6E91653: client_dispose (client.c:332) ==9237== by 0x6E9476A: sasl_dispose (common.c:851) ==9237== by 0x4E225A1: virNetSASLSessionDispose (virnetsaslcontext.c:678) ==9237== by 0x4CBC551: virObjectUnref (virobject.c:262) ==9237== by 0x4E254D1: virNetSocketDispose (virnetsocket.c:1042) ==9237== by 0x4CBC551: virObjectUnref (virobject.c:262) ==9237== by 0x4E2701C: virNetSocketEventFree (virnetsocket.c:1794) ==9237== by 0x4C965D3: virEventPollCleanupHandles (vireventpoll.c:583) ==9237== by 0x4C96987: virEventPollRunOnce (vireventpoll.c:652) ==9237== by 0x4C94730: virEventRunDefaultImpl (virevent.c:274) ==9237== by 0x12C7BA: vshEventLoop (virsh.c:2407) ==9237== by 0x4CD3D04: virThreadHelper (virthreadpthread.c:161) ==9237== by 0x7DAEF32: start_thread (pthread_create.c:309) ==9237== by 0x8C86EAC: clone (clone.S:111) ==9237== Address 0xe2d61b0 is 0 bytes inside a block of size 168 free'd ==9237== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==9237== by 0x4C73827: virFree (viralloc.c:580) ==9237== by 0x4DE4BC7: remoteAuthSASL (remote_driver.c:4219) ==9237== by 0x4DE33D0: remoteAuthenticate (remote_driver.c:3639) ==9237== by 0x4DDBFAA: doRemoteOpen (remote_driver.c:832) ==9237== by 0x4DDC8DC: remoteConnectOpen (remote_driver.c:1031) ==9237== by 0x4D8595F: do_open (libvirt.c:1239) ==9237== by 0x4D863F3: virConnectOpenAuth (libvirt.c:1481) ==9237== by 0x12762B: vshReconnect (virsh.c:337) ==9237== by 0x12C9B0: vshInit (virsh.c:2470) ==9237== by 0x12E9A5: main (virsh.c:3338) This commit changes virNetSASLSessionNewClient() to take ownership of the SASL callbacks. Then we can free them in virNetSASLSessionDispose() after the corresponding sasl_conn_t has been freed. (cherry picked from commit 13fdc6d6)
-
由 Jiri Denemark 提交于
The previous attempt (commit d65e0e14) removed just one of two libvirt-guests restarts that happened on libvirt-client update. Let's remove the last one too :-) https://bugzilla.redhat.com/show_bug.cgi?id=962225Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 604f79b3)
-
由 Don Dugger 提交于
This Python interface code is returning a -1 on errors for the `baselineCPU' API. Since this API is supposed to return a pointer the error return value should really be VIR_PY_NONE. NB: I've checked all the other APIs in this file and this is the only pointer API that is returning -1. Signed-off-by: NDon Dugger <donald.d.dugger@intel.com> (crobinso: Upstream in libvirt-python.git)
-
- 10 12月, 2013 6 次提交
-
-
由 Cole Robinson 提交于
We were unconditionally removing the device from the host list, when it should only be done on error. This fixes USB collision detection when hotplugging the same device to two guests. (cherry picked from commit 586b0ed8)
-
由 Cole Robinson 提交于
If we hit a collision, we free the USB device while it is still part of our temporary USBDeviceList. When the list is unref'd, the device is free'd again. Make the initial device freeing dependent on whether it is present in the temporary list or not. (cherry picked from commit 5953a737)
-
由 Cole Robinson 提交于
Similar to what Jiri did for cgroup setup/teardown in 05e149f9, push it all into the device handler functions so we can do the necessary prep work before claiming the device. This also fixes hotplugging USB devices by product/vendor (virt-manager's default behavior): https://bugzilla.redhat.com/show_bug.cgi?id=1016511 (cherry picked from commit ee414b5d)
-
由 Cole Robinson 提交于
They aren't used outside of qemu_hotplug.c (cherry picked from commit 79776aa5)
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1025108 So far qemuSetupHostdevCGroup was called very early during hotplug, even before we knew the device we were about to hotplug was actually available. By calling the function later, we make sure QEMU won't be allowed to access devices used by other domains. Another important effect of this change is that hopluging USB devices specified by vendor and product (but not by their USB address) works again. This was broken since v1.0.5-171-g7d763aca, when the call to qemuFindHostdevUSBDevice was moved after the call to qemuSetupHostdevCGroup, which then used an uninitialized USB address. (cherry picked from commit 05e149f9)
-
由 Peter Krempa 提交于
To simplify future patches dealing with this code, simplify and refactor some conditions to switch statements. (cherry picked from commit 9d132989)
-
- 03 12月, 2013 1 次提交
-
-
由 Peter Krempa 提交于
When doing an internal snapshot on a VM with sheepdog or RBD disks we would not set a flag to mark the domain is using internal snapshots and might end up creating a mixed snapshot. Move the setting of the variable to avoid this problem. (cherry picked from commit d8cf91ae)
-
- 22 11月, 2013 1 次提交
-
-
由 Cole Robinson 提交于
Restarting an active libvirt-guests.service is the equivalent of doing: /usr/libexec/libvirt-guests.sh stop /usr/libexec/libvirt-guests.sh start Which in a default configuration will managedsave every running VM, and then restore them. Certainly not something we should do every time the libvirt-client RPM is updated. Just drop the try-restart attempt, I don't know what purpose it serves anyways. https://bugzilla.redhat.com/show_bug.cgi?id=962225 (cherry picked from commit d65e0e14)
-
- 20 11月, 2013 3 次提交
-
-
由 Daniel P. Berrange 提交于
If the host side of an LXC container console disconnected and the guest side continued to write data, until the PTY buffer filled up, the LXC controller would busy wait. It would repeatedly see POLLHUP from poll() and not disable the watch. This was due to some bogus logic detecting blocking conditions. Upon seeing a POLLHUP we must disable all reading & writing from the PTY, and setup the epoll to wake us up again when the connection comes back. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 5087a5a0)
-
由 Cole Robinson 提交于
Possible fix for occasional libvirt-guests failure at boot time: https://bugzilla.redhat.com/show_bug.cgi?id=906009 (cherry picked from commit d9203675)
-
由 Guido Günther 提交于
Syslog is socket activated since at least systemd v35 so we can drop this dependency. Debian's linitian otherwise complains about it. References: http://www.freedesktop.org/wiki/Software/systemd/syslog/ http://lintian.debian.org/tags/systemd-service-file-refers-to-obsolete-target.html (cherry picked from commit 3c9e40a1)
-
- 18 11月, 2013 3 次提交
-
-
由 Michael Avdienko 提交于
QEMU 1.6.0 introduced new migration status: setup Libvirt does not expect such string in QMP and refuses to migrate with error "unexpected migration status in setup" This patch fixes it. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit d35ae414)
-
由 Jeremy Fitzhardinge 提交于
Rather than casting the virBitmap pointer to uint8_t* and then using the structure contents as a byte array, use the virBitmap API to determine the bitmap size and test each bit. Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org> (cherry picked from commit ba1bf100)
-
由 Laine Stump 提交于
This should resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1012085 libvirt previously recognized NFS, GFS2, OCFS2, and AFS filesystems as "shared", and thus eligible for exceptions to certain rules/actions about chowning image files before handing them off to a guest. This patch widens the definition of "shared filesystem" to include SMB and CIFS filesystems (aka "Windows file sharing"); both of these use the same protocol, but different drivers so there are different magic numbers for each. (cherry picked from commit e4e73337)
-
- 13 11月, 2013 3 次提交
-
-
由 Ján Tomko 提交于
When opening a new connection to the driver, nwfilterOpen only succeeds if the driverState has been allocated. Move the privilege check in driver initialization before the state allocation to disable the driver. This changes the nwfilter-define error from: error: cannot create config directory (null): Bad address To: this function is not supported by the connection driver: virNWFilterDefineXML https://bugzilla.redhat.com/show_bug.cgi?id=1029266 (cherry picked from commit b7829f95)
-
由 Ján Tomko 提交于
Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2]) '-no-kvm-pit-reinjection' has been deprecated. Use -global kvm-pit.lost_tick_policy=discard instead. https://bugzilla.redhat.com/show_bug.cgi?id=978719 [1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39 [2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f (cherry picked from commit 1569fa14) Conflicts: tests/qemucapabilitiesdata/caps_1.2.2-1.caps tests/qemucapabilitiesdata/caps_1.2.2-1.replies tests/qemucapabilitiesdata/caps_1.3.1-1.caps tests/qemucapabilitiesdata/caps_1.3.1-1.replies tests/qemucapabilitiesdata/caps_1.4.2-1.caps tests/qemucapabilitiesdata/caps_1.4.2-1.replies tests/qemucapabilitiesdata/caps_1.5.3-1.caps tests/qemucapabilitiesdata/caps_1.5.3-1.replies tests/qemucapabilitiesdata/caps_1.6.0-1.caps tests/qemucapabilitiesdata/caps_1.6.0-1.replies tests/qemucapabilitiesdata/caps_1.6.50-1.caps tests/qemucapabilitiesdata/caps_1.6.50-1.replies (qemucapabilitiestest is not backported)
-
由 Michal Privoznik 提交于
Since 86d90b3a (yes, my patch; again) we are supporting NBD storage migration. However, on error recovery path we got the steps reversed. The correct order is: return NBD port to the virPortAllocator and then either unlock the vm or remove it from the driver. Not vice versa. ==11192== Invalid write of size 4 ==11192== at 0x11488559: qemuMigrationPrepareAny (qemu_migration.c:2459) ==11192== by 0x11488EA6: qemuMigrationPrepareDirect (qemu_migration.c:2652) ==11192== by 0x114D1509: qemuDomainMigratePrepare3Params (qemu_driver.c:10332) ==11192== by 0x519075D: virDomainMigratePrepare3Params (libvirt.c:7290) ==11192== by 0x1502DA: remoteDispatchDomainMigratePrepare3Params (remote.c:4798) ==11192== by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741) ==11192== by 0x5212127: virNetServerProgramDispatchCall (virnetserverprogram.c:435) ==11192== by 0x5211C86: virNetServerProgramDispatch (virnetserverprogram.c:305) ==11192== by 0x520A8FD: virNetServerProcessMsg (virnetserver.c:165) ==11192== by 0x520A9E1: virNetServerHandleJob (virnetserver.c:186) ==11192== by 0x50DA78F: virThreadPoolWorker (virthreadpool.c:144) ==11192== by 0x50DA11C: virThreadHelper (virthreadpthread.c:161) ==11192== Address 0x1368baa0 is 576 bytes inside a block of size 688 free'd ==11192== at 0x4A07F5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11192== by 0x5079A2F: virFree (viralloc.c:580) ==11192== by 0x11456C34: qemuDomainObjPrivateFree (qemu_domain.c:267) ==11192== by 0x50F41B4: virDomainObjDispose (domain_conf.c:2034) ==11192== by 0x50C2991: virObjectUnref (virobject.c:262) ==11192== by 0x50F4CFC: virDomainObjListRemove (domain_conf.c:2361) ==11192== by 0x1145C125: qemuDomainRemoveInactive (qemu_domain.c:2087) ==11192== by 0x11488520: qemuMigrationPrepareAny (qemu_migration.c:2456) ==11192== by 0x11488EA6: qemuMigrationPrepareDirect (qemu_migration.c:2652) ==11192== by 0x114D1509: qemuDomainMigratePrepare3Params (qemu_driver.c:10332) ==11192== by 0x519075D: virDomainMigratePrepare3Params (libvirt.c:7290) ==11192== by 0x1502DA: remoteDispatchDomainMigratePrepare3Params (remote.c:4798) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 1f2f879e)
-
- 12 11月, 2013 2 次提交
-
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1018897 If a PCI deivce is not binded to any driver (e.g. there's yet no PCI driver in the linux kernel) but still users want to passthru the device we fail the whole operation as we fail to resolve the 'driver' link under the PCI device sysfs tree. Obviously, this is not a fatal error and it shouldn't be error at all. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit df4283a5)
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1027096 If there's the following snippet in the domain XML, the domain will be lost upon the daemon restart (if the domain is started prior restart): <seclabel type='dynamic' relabel='yes'/> The problem is, the 'label', 'imagelabel' and 'baselabel' are parsed whenever the VIR_DOMAIN_XML_INACTIVE is *not* present or the label is static. The latter is not our case, obviously. So, when libvirtd starts up, it finds domain state xml and parse it. During parsing, many XML flags are enabled but VIR_DOMAIN_XML_INACTIVE. Hence, our parser tries to extract 'label', 'imagelabel' and 'baselabel' from the XML which fails for model='none'. Err, this model - even though not specified in XML - can be taken from qemu wide config file: /etc/libvirtd/qemu.conf. However, in order to know we are dealing with model='none' the code in question must be moved forward a bit. Then a new check must be introduced. This is what the first two chunks are doing. But this alone is not sufficient. The domain state XML won't contain the model attribute without slight modification. The model should be inserted into the XML even if equal to 'none' and the state XML is being generated - what if the origin (the @security_driver variable in qemu.conf) changes during libvirtd restarts? At the end, a test to catch this scenario is introduced. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 9fb3f957)
-
- 07 11月, 2013 5 次提交
-
-
由 Cole Robinson 提交于
-
由 Daniel P. Berrange 提交于
For inexplicable reasons, many of the 3rd party package deps were left against the 'libvirt-daemon' RPM when the drivers were split out. This makes a minimal install heavier that it should be. Push them all down into libvirt-daemon-driver-XXX so they're only pulled in when truly needed With this change applied, a minimal install of just the libvirt-daemon-driver-lxc RPM is reduced by 41 MB on a Fedora 19 host. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 23142ac9)
-
由 Daniel P. Berrange 提交于
The following sequence 1. Define a persistent QMEU guest 2. Start the QEMU guest 3. Stop libvirtd 4. Kill the QEMU process 5. Start libvirtd 6. List persistent guests At the last step, the previously running persistent guest will be missing. This is because of a race condition in the QEMU driver startup code. It does 1. Load all VM state files 2. Spawn thread to reconnect to each VM 3. Load all VM config files Only at the end of step 3, does the 'virDomainObjPtr' get marked as "persistent". There is therefore a window where the thread reconnecting to the VM will remove the persistent VM from the list. The easy fix is to simply switch the order of steps 2 & 3. In addition to this though, we must only attempt to reconnect to a VM which had a non-zero PID loaded from its state file. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit f26701f5)
-
由 Daniel P. Berrange 提交于
The 'error' cleanup block in qemuProcessReconnect() had a 'return' statement in the middle of it. This caused a leak of virConnectPtr & virQEMUDriverConfigPtr instances. This was identified because netcf recently started checking its refcount in libvirtd shutdown: netcfStateCleanup:109 : internal error: Attempt to close netcf state driver with open connections Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 54a24112)
-
由 Daniel P. Berrange 提交于
virDomainObjListLoadAllConfigs sets dom->persistent after having released its lock on the domain object. This exposes a possible race condition. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit b260a77e)
-
- 30 10月, 2013 10 次提交
-
-
由 Daniel P. Berrange 提交于
Avoid people introducing security flaws in their apps by forbidding the use of libvirt.so in setuid programs, with a check in virInitialize. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 9cd6a57d)
-
由 Daniel P. Berrange 提交于
Most of the usage of getuid()/getgid() is in cases where we are considering what privileges we have. As such the code should be using the effective IDs, not real IDs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 9b0af092)
-
由 Daniel P. Berrange 提交于
We already have stubs for getuid, geteuid, getgid but not for getegid. Something in gnulib already does a check for it during configure, so we already have the HAVE_GETEGID macro defined. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit c566fa1a)
-
由 Daniel P. Berrange 提交于
We don't want setuid programs automatically spawning libvirtd, so disable any use of autostart when setuid. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 171bb129)
-
由 Daniel P. Berrange 提交于
We don't know enough about quality of external libraries used for non-UNIX transports, nor do we want to spawn external commands when setuid. Restrict to the bare minimum which is UNIX transport for local usage. Users shouldn't need to be running setuid if connecting to remote hypervisors in any case. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e22b0232)
-
由 Daniel P. Berrange 提交于
The use of getenv is typically insecure, and we want people to use our wrappers, to force them to think about setuid needs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 71b21f12)
-
由 Daniel P. Berrange 提交于
Unconditional use of getenv is not secure in setuid env. While not all libvirt code runs in a setuid env (since much of it only exists inside libvirtd) this is not always clear to developers. So make all the code paranoid, even if it only ever runs inside libvirtd. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 1e4a02bd)
-
由 Daniel P. Berrange 提交于
When running setuid, we must be careful about what env vars we allow commands to inherit from us. Replace the virCommandAddEnvPass function with two new ones which do filtering virCommandAddEnvPassAllowSUID virCommandAddEnvPassBlockSUID And make virCommandAddEnvPassCommon use the appropriate ones Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 9b8f307c)
-
由 Daniel P. Berrange 提交于
In Fedora 20, libvirt_lxc crashes immediately at startup with a trace #0 0x00007f0cddb653ec in free () from /lib64/libc.so.6 #1 0x00007f0ce0e16f4a in virFree (ptrptr=ptrptr@entry=0x7f0ce1830058) at util/viralloc.c:580 #2 0x00007f0ce0e2764b in virResetError (err=0x7f0ce1830030) at util/virerror.c:354 #3 0x00007f0ce0e27a5a in virResetLastError () at util/virerror.c:387 #4 0x00007f0ce0e28858 in virEventRegisterDefaultImpl () at util/virevent.c:233 #5 0x00007f0ce0db47c6 in main (argc=11, argv=0x7fff4596c328) at lxc/lxc_controller.c:2352 Normally virInitialize calls virErrorInitialize and virThreadInitialize, but we don't link to libvirt.so in libvirt_lxc, and nor did we ever call the error or thread initializers. I have absolutely no idea how this has ever worked, let alone what caused it to stop working in Fedora 20. In addition not all code paths from virLogSetFromEnv will ensure virLogInitialize is called correctly, which is another possible crash scenario. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 97973ebb)
-
由 Daniel P. Berrange 提交于
The log message regex has been [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}\+[0-9]{4}: [0-9]+: debug|info|warning|error : The precedence of '|' is high though, so this is equivalent to matching [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}\+[0-9]{4}: [0-9]+: debug Or info Or warning Or error : Which is clearly not what it should have done. This caused the code to skip over things which are not log messages. The solution is to simply add brackets. A test case is also added to validate correctness. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 5787f0b9)
-
- 23 10月, 2013 3 次提交
-
-
由 Daniel P. Berrange 提交于
Many people will not want the setuid virt-login-shell binary installed by default, so move it into a separate sub-RPM named libvirt-login-shell. This RPM is only generated if LXC is enabled Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 8adc9269)
-
由 Daniel P. Berrange 提交于
The virt-login-shell binary shouldn't need to execute programs relying on $PATH, but just in case set a fixed $PATH value of /bin:/usr/bin Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit d665003d)
-
由 Zhou Yimin 提交于
Introduced by 7b87a3 When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT, I got error like: "libvirt: XML-RPC error : internal error: domain event 0 not registered". Then I add the following code, it fixed. Signed-off-by: NZhou Yimin <zhouyimin@huawei.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 9712c251)
-