- 10 12月, 2011 11 次提交
-
-
由 Laine Stump 提交于
One of the xml tests in the test suite was created using a now-deprecated qemu machine type ("fedora-13", which was only ever valid for Fedora builds of qemu). Although strictly speaking it's not necessary to replace it with an actual supported qemu machine type (since the xml in question is never actually sent to qemu), this patch changes it to the actually-supported "pc-0.13" just for general tidiness. (Also, on some Fedora builds which contain a special patch to rid the world of "fedora-13", having it mentioned in the test suite will cause make check to fail.)
-
由 Laine Stump 提交于
This patch addresses https://bugzilla.redhat.com/show_bug.cgi?id=760442 When a network has any forward type other than route, nat or none, the network configuration should be done completely external to libvirt - libvirt only uses these types to allow configuring guests in a manner that isn't tied to a specific host (all the host-specific information, in particular interface names, port profile data, and bandwidth configuration is in the network definition, and the guest configuration only references it). Due to a bug in the bridge network driver, libvirt was adding iptables rules for networks with forward type='bridge' etc. any time libvirtd was restarted while one of these networks was active. This patch eliminates that error by only "reloading" iptables rules if forward type is route, nat, or none.
-
由 Michael Ellerman 提交于
Currently qemuDomainAssignPCIAddresses() is called to assign addresses to PCI devices. We need to do something similar for devices with spapr-vio addresses. So create one place where address assignment will be done, that is qemuDomainAssignAddresses(). Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
由 Michael Ellerman 提交于
For the PPC64 pseries machine type we need to add address information for the spapr-vty device. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
由 Michael Ellerman 提交于
On the PPC64 pseries machine type we need to use the spapr-vscsi device rather than an lsi. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
-
由 Eric Blake 提交于
In QEMU PPC64 we have a network device called "spapr-vlan". We can specify this using the existing syntax for network devices, however libvirt currently rejects "spapr-vlan" in virDomainNetDefParseXML() because of the "-". Fix the code to accept "-". * src/conf/domain_conf.c (virDomainNetDefParseXML): Allow '-' in model name, and be more efficient. * docs/schemas/domaincommon.rng: Limit valid model names to match code. Based on a patch by Michael Ellerman.
-
由 Michal Privoznik 提交于
instead of simple 'if' statement as virCondWait can return even if associated condition was not signaled.
-
由 Michal Privoznik 提交于
-
由 Alex Jia 提交于
Detected by valgrind. Leak introduced in commit 88a993b1: * tools/virsh.c: fix memory leak on cmdDomblklist. * how to reproduce? % valgrind -v --leak-check=full virsh domblklist <domain name> * actual valgrind result: ==6573== 1,836 bytes in 1 blocks are definitely lost in loss record 110 of 124 ==6573== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==6573== by 0x330D71497D: xdr_string (in /lib64/libc-2.12.so) ==6573== by 0x4D26CED: xdr_remote_nonnull_string (remote_protocol.c:30) ==6573== by 0x4D28138: xdr_remote_domain_get_xml_desc_ret (remote_protocol.c:1418) ==6573== by 0x4D3C0C2: virNetMessageDecodePayload (virnetmessage.c:382) ==6573== by 0x4D3279F: virNetClientProgramCall (virnetclientprogram.c:382) ==6573== by 0x4D0D50B: callWithFD (remote_driver.c:4339) ==6573== by 0x4D0D5AB: call (remote_driver.c:4360) ==6573== by 0x4D16EAF: remoteDomainGetXMLDesc (remote_client_bodies.h:861) ==6573== by 0x4CF9F4F: virDomainGetXMLDesc (libvirt.c:4098) ==6573== by 0x4154D9: cmdDomblklist (virsh.c:1722) ==6573== by 0x4149E2: vshCommandRun (virsh.c:16365) ==6573== ==6573== 46,009 (352 direct, 45,657 indirect) bytes in 1 blocks are definitely lost in loss record 123 of 124 ==6573== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==6573== by 0x3318286DC6: xmlXPathNewContext (in /usr/lib64/libxml2.so.2.7.6) ==6573== by 0x4C79AE2: virXMLParseHelper (xml.c:779) ==6573== by 0x415512: cmdDomblklist (virsh.c:1726) ==6573== by 0x4149E2: vshCommandRun (virsh.c:16365) ==6573== by 0x427743: main (virsh.c:17867) ==6573== ==6573== LEAK SUMMARY: ==6573== definitely lost: 2,188 bytes in 2 blocks ==6573== indirectly lost: 45,657 bytes in 332 blocks ==6573== possibly lost: 0 bytes in 0 blocks ==6573== still reachable: 128,034 bytes in 1,364 blocks ==6573== suppressed: 0 bytes in 0 blocks Signed-off-by: NAlex Jia <ajia@redhat.com>
-
由 Stefan Berger 提交于
When parsing ppc64 models on an x86 host an out-of-memory error message is displayed due to it checking for retcpus being NULL. Fix this by removing the check whether retcpus is NULL since we will realloc into this variable. Also in the X86 model parser display the OOM error at the location where it happens.
-
由 Stefan Berger 提交于
Fix memory leak: ==27534== 24 bytes in 1 blocks are definitely lost in loss record 207 of 530 ==27534== at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==27534== by 0x38EC26EC37: vasprintf (in /lib64/libc-2.13.so) ==27534== by 0x4E998E6: virVasprintf (util.c:1677) ==27534== by 0x4E999F1: virAsprintf (util.c:1695) ==27534== by 0x4F1EAAC: nodeGetInfo (nodeinfo.c:593) ==27534== by 0x47948F: qemuCapsInitCPU (qemu_capabilities.c:855) ==27534== by 0x4796B1: qemuCapsInit (qemu_capabilities.c:915) ==27534== by 0x456550: qemuCreateCapabilities (qemu_driver.c:245) ==27534== by 0x4578C4: qemudStartup (qemu_driver.c:580) ==27534== by 0x4F20886: virStateInitialize (libvirt.c:852) ==27534== by 0x420E55: daemonRunStateInit (libvirtd.c:1156) ==27534== by 0x4E94C56: virThreadHelper (threads-pthread.c:157) Mark this leaked variable as const char * when it is passed into another function.
-
- 09 12月, 2011 12 次提交
-
-
由 Michal Privoznik 提交于
Pool creates new workers dynamically. However, it is possible for a pool to have no workers. If we want to free that pool, we don't want to wait on quit condition as it will never be signaled.
-
由 Jiri Denemark 提交于
Due to copy&paste error in c1df2c14, virNetDevBridge[SG]etSTPDelay APIs were accessing wrong file.
-
由 Peter Krempa 提交于
Add support for newly supported Intel cpu features. Newly supported flags are: pclmuldq, dtes64, smx, fma, pdcm, movbe, xsave, osxsave and avx. This adds support for Intel's Sandy Bridge platform.
-
由 Peter Krempa 提交于
Reported by Alex Jia <ajia@redhat.com>. Function cmdDomIfGetLink did not set a success return value on success path. Signed-off-by: Alex Jia<ajia@redhat.com>
-
由 Stefan Berger 提交于
A preparatory patch for DHCP snooping where we want to be able to differentiate between a VM's interface using the tuple of <VM UUID, Interface MAC address>. We assume that MAC addresses could possibly be re-used between different networks (VLANs) thus do not only want to rely on the MAC address to identify an interface. At the current 'final destination' in virNWFilterInstantiate I am leaving the vmuuid parameter as ATTRIBUTE_UNUSED until the DHCP snooping patches arrive. (we may not post the DHCP snooping patches for 0.9.9, though) Mostly this is a pretty trivial patch. On the lowest layers, in lxc_driver and uml_conf, I am passing the virDomainDefPtr around until I am passing only the VM's uuid into the NWFilter calls.
-
由 Stefan Berger 提交于
This patch cleans up return codes in the nwfilter subsystem. Some functions in nwfilter_conf.c (validators and formatters) are keeping their bool return for now and I am converting their return code to true/false. All other functions now have failure return codes of -1 and success of 0. [I searched for all occurences of ' 1;' and checked all 'if ' and adapted where needed. After that I did a grep for 'NWFilter' in the source tree.]
-
由 Alex Jia 提交于
Detected by valgrind. Leak introduced in commit dc675f37: * tools/virsh.c: fix memory leak on cmdDomIfGetLink. * how to reproduce? % valgrind -v --leak-check=full virsh domif-getlink <domain name> 0 * actual valgrind result: ==13102== 18 bytes in 1 blocks are definitely lost in loss record 9 of 47 ==13102== at 0x4A05FDE: malloc (vg_replace_malloc.c:236) ==13102== by 0x322A6A67DD: xmlStrndup (in /usr/lib64/libxml2.so.2.7.6) ==13102== by 0x414892: cmdDomIfGetLink (virsh.c:1538) ==13102== by 0x4136A2: vshCommandRun (virsh.c:16363) ==13102== by 0x4253FB: main (virsh.c:17865) ==13102== ==13102== LEAK SUMMARY: ==13102== definitely lost: 18 bytes in 1 blocks ==13102== indirectly lost: 0 bytes in 0 blocks ==13102== possibly lost: 0 bytes in 0 blocks ==13102== still reachable: 127,888 bytes in 1,361 blocks ==13102== suppressed: 0 bytes in 0 blocks Signed-off-by: NAlex Jia <ajia@redhat.com>
-
由 Alex Jia 提交于
Detected by valgrind. Leak introduced in commit e9bd9a08: * tools/virsh.c: fix memory leak on cmdBlkdeviotune. * how to reproduce? % valgrind -v --leak-check=full virsh blkdeviotune <domain name> <block device> * actual valgrind result: ==12759== 576 bytes in 1 blocks are definitely lost in loss record 18 of 29 ==12759== at 0x4A04A28: calloc (vg_replace_malloc.c:467) ==12759== by 0x42134E: _vshCalloc.clone.2 (virsh.c:422) ==12759== by 0x4217CB: cmdBlkdeviotune (virsh.c:6364) ==12759== by 0x4136A2: vshCommandRun (virsh.c:16363) ==12759== by 0x4253FB: main (virsh.c:17865) ==12759== ==12759== LEAK SUMMARY: ==12759== definitely lost: 576 bytes in 1 blocks ==12759== indirectly lost: 0 bytes in 0 blocks ==12759== possibly lost: 0 bytes in 0 blocks ==12759== still reachable: 126,964 bytes in 1,342 blocks ==12759== suppressed: 0 bytes in 0 blocks Signed-off-by: NAlex Jia <ajia@redhat.com>
-
由 Eric Blake 提交于
Jiri Denemark reported an instance of bootstrapping libvirt failing when run inside a sandbox, traced to rpm trying to access /var/ which was not permitted by the sandbox. Alex Jia reported that 0.9.8-rc1 failed to bootstrap if patch(1) is not installed. * bootstrap.conf (buildreq): Avoid rpm call if python-config exists. Also, require patch, in case we have gnulib-local diffs.
-
由 Laine Stump 提交于
In some error situations, the function testDomainRestoreFlags() could unlock the test driver mutex without first locking it. This patch moves the lock operation earlier, so that it occurs before any potential jump down to the unlock call. I found this problem while auditing the test driver lock usage to determine the cause of a hang while running the following test: cd tests; while true; do printf x; ./undefine; done This patch *does not* solve that problem, but we now understand its actual source, and danpb is working on a patch.
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=738725 Commit ecd8725c tried to silence a spurious warning on the initial libvirt install, and commit ba6cbb18 tried to fix up the logic to the correct Fedora version, but the warning was still present due to a logic bug: since %{fedora} and %{rhel} are never simulatanously set, then 0%{rhel} <= 6 made the %if always true. Checking for minimum versions (via >=) is okay, but checking for maximum versions (via <=) requires a prerequisite test that the platform being tested is non-zero. Also fix a bogus setting of with_libxl (although we previously hard-code with_libxl to 0 for rhel earlier in the file, so this was not as severe a bug). * libvirt.spec.in (with_cgconfig): Don't enable cgconfig on F16.
-
由 Eric Blake 提交于
Over time, Fedora and RHEL RPMs have often backported upstream patches that touched configure.ac and/or Makefile.am; this necessitates rerunning the autotools for the patch to be effective. Making this a one-liner spec tweak will make it easier for future backports to pull patches without having to find all the places to touch to properly use the autotools. Meanwhile, there have been historical instances where an update in the autotools caused FTBFS situations, so this is not on by default. * libvirt.spec.in (enable_autotools): New variable, default off. (BuildRequires): Conditionally add autotools. (%build): Conditionally use them before configure. * mingw32-libvirt.spec.in: Likewise.
-
- 08 12月, 2011 17 次提交
-
-
由 Daniel P. Berrange 提交于
* src/lxc/lxc_controller.c: Fix check for tty count
-
由 Daniel P. Berrange 提交于
The installation rules for the libvirt-guests.service were totally broken - Installing in the wrong location - The location was not overridable - The install-systemd rule was not invoked anywhere - The install-systemd rule was not invoking install-initscript which it depends on - The installed service file lacked a .service extension * tools/Makefile.am: Fix install of libvirt-guests.service
-
由 Daniel P. Berrange 提交于
The %makeinstall macro does not set DESTDIR, instead of explicitly prefixes %{buildroot} onto all paths. Thus we need to do the same when setting the systemd unit dir * libvirt.spec.in: Prefix %{buildroot} onto %{unitdir}
-
由 Bharata B Rao 提交于
ppc64 as new arch type and pseries as new machine type are added under <os> ... </os>. Signed-off-by: NBharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Prerna Saxena 提交于
assumptions from generic code. This implements the minimal set of changes needed in libvirt to launch a PowerPC-KVM based guest. It removes x86-specific assumptions about choice of serial driver backend from generic qemu guest commandline generation code. It also restricts the ACPI capability to be available for an x86 or x86_64 domain. This is not a complete solution -- it still does not guarantee libvirt the capability to flag non-supported options in guest XML. (Eg, an ACPI specification in a PowerPC guest XML will still get processed, even though qemu-system-ppc64 does not support it while qemu-system-x86_64 does.) This drawback exists because libvirt falls back on qemu to query supported features, and qemu '-h' blindly lists all capabilities -- irrespective of whether they are available while emulating a given architecture or not. The long-term solution would be for qemu to list out capabilities based on architecture and platform -- so that libvirt can cleanly make out what devices are supported on an arch (say 'ppc64') and platform (say, 'mac99'). Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Prerna Saxena 提交于
This enables libvirt to select the correct qemu binary (qemu-system-ppc64) for a guest vm based on arch 'ppc64'. Also, libvirt is enabled to correctly parse the list of supported PowerPC CPUs, generated by running 'qemu-system-ppc64 -cpu ?' Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com> Acked-by: NStefan Berger <stefanb@linux.vnet.ibm.com>
-
由 Prerna Saxena 提交于
to proc/cpuinfo This patch creates a new sysfs hierarchy under tests/nodeinfodata/linux-nodeinfo-sysfs-test-1. Output files and /proc/cpuinfo files are also respectively added for both x86 and ppc64. Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Prerna Saxena 提交于
/proc/cpuinfo Libvirt at present depends on /proc/cpuinfo to gather host details such as CPUs, cores, threads, etc. This is an architecture- dependent approach. An alternative is to use 'Sysfs', which provides a platform-agnostic interface to parse host CPU topology. Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
由 Christophe Fergeau 提交于
Since I have commit rights on libvirt-glib, I can also push to libvirt, Eric Blake told to move my name up to committers to better reflect reality.
-
由 Daniel Veillard 提交于
* configure.ac docs/news.html.in libvirt.spec.in: updated for the release * po/*.po*: fetched localization update and regenerated
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=694403 reports that the specfile is incorrectly checking for a running libvirt-guests service. For example, $ LC_ALL=es_ES chkconfig --list libvirt-guests libvirt-guests 0:desactivado 1:desactivado 2:desactivado 3:activo 4:activo 5:activo 6:desactivado will fail to find 5:on, even though it is active. But chkconfig already has a mode where you can silently use the exit status to check for an active service. * libvirt.spec.in (%post): Use simpler chkconfig options, to avoid issues with localization.
-
由 Eric Blake 提交于
On RHEL 5, with libxml2-2.6.26, the build failed with: virsh.c: In function 'vshNodeIsSuperset': virsh.c:11951: warning: implicit declaration of function 'xmlChildElementCount' (or if warnings aren't errors, a link failure later on). * src/util/xml.h (virXMLChildElementCount): New prototype. * src/util/xml.c (virXMLChildElementCount): New function. * src/libvirt_private.syms (xml.h): Export it. * tools/virsh.c (vshNodeIsSuperset): Use it.
-
由 Daniel P. Berrange 提交于
When one thread passes the buck to another thread, it uses virCondSignal to wake up the target thread. The variable 'haveTheBuck' is not updated in a race-free manner when this occurs. The current thread sets it to false, and the woken up thread sets it to true. There is a window where a 3rd thread can come in and grab the buck. Even if this didn't lead to crashes & deadlocks, this would still result in unfairness in the buckpassing algorithm. A better solution is to *never* set haveTheBuck to false when we're passing the buck. Only set it to false when there is no further thread waiting for the buck. * src/rpc/virnetclient.c: Only set haveTheBuck to false if no thread is waiting
-
由 Daniel P. Berrange 提交于
Commit fd066925 tried to fix a race condition in commit fa959500 Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Nov 11 15:28:41 2011 +0000 Explicitly track whether the buck is held in remote client Unfortunately there is a second race condition whereby the event loop can trigger due to incoming data to read. Revert this fix, so a complete fix for the problem can be cleanly applied * src/rpc/virnetclient.c: Revert fd066925
-
由 Jim Fehlig 提交于
With security_driver set to "none" in /etc/libvirt/qemu.conf, libvirtd would crash when attempted to attach to an existing qemu process. Only copy the security model if it actually exists.
-
由 Christophe Fergeau 提交于
-
由 Christophe Fergeau 提交于
It's referring to virSuspendDomain instead of virDomainSuspend.
-