- 06 11月, 2014 10 次提交
-
-
由 Martin Kletzander 提交于
This is a reaction to Michal's fix [1] for non-NUMA systems that also splits out conf/ out of util/ because libvirt_util shouldn't require libvirt_conf if it is the other way around. This particular use case worked, but we're trying to avoid it as mentioned [2], many times. The only functions from virnuma.c that needed numatune_conf were virDomainNumatuneNodesetIsAvailable() and virNumaSetupMemoryPolicy(). The first one should be in numatune_conf as it works with virDomainNumatune, the second one just needs nodeset and mode, both of which can be passed without the need of numatune_conf. Apart from fixing that, this patch also fixes recently added code (between commits d2460f85^..5c851562) that doesn't support non-contiguous nodesets. It uses new function virNumaNodesetIsAvailable(), which doesn't need a stub as it doesn't use any libnuma functions, to check if every specified nodeset is available. [1] https://www.redhat.com/archives/libvir-list/2014-November/msg00118.html [2] http://www.redhat.com/archives/libvir-list/2011-June/msg01040.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
When using git-status during configure phase, three additional files are shown as untracked. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Erik Skultety 提交于
Patch 43b67f2e disallowed network tuning only with qemu driver, however this patch moved the check for root privileges into virNetDevBandwidthSet function, so the call should now fail in all possible cases. A mock function was created so that the test suite doesn't fail because of unsufficient privileges.
-
由 Erik Skultety 提交于
Since there was a valid note to patch 43b67f2e about the best spot to check for bandwidth set call while having libvirt daemon run in session mode, this patch reverts previous changes dealing with bandwith (also reverts adding variable @cfg in qemuDomainGetNumaParameters which does not have any use at the moment, but getting and unreferencing driver's config) in qemu_driver.c and qemu_command.c. There will be another patch in the series which introduces the fix itself.
-
由 Ján Tomko 提交于
==404== 232 bytes in 1 blocks are definitely lost in loss record 669 of 758 ==404== at 0x4C2B934: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==404== by 0x52A2BF3: virAlloc (viralloc.c:144) ==404== by 0x1D49AD70: qemuMigrationCookieAddStatistics (qemu_migration.c:554) ==404== by 0x1D49AD70: qemuMigrationBakeCookie (qemu_migration.c:1228) ==404== by 0x1D4A43B8: qemuMigrationFinish (qemu_migration.c:5002) ==404== by 0x1D4C9339: qemuDomainMigrateFinish3Params (qemu_driver.c:11526) Introduced by commit 5d6fb963
-
由 Hao Liu 提交于
Bandwidth options in blockcommit, blockcopy, blockjob and blockpull are parsed by vshCommandOptULWrap() and should be shown as a number type option. And a typo is fixed. Signed-off-by: NHao Liu <hliu@redhat.com>
-
由 Michal Privoznik 提交于
As of 90286418 the function is introduced. However, it's missing an entry in the libvirt_private.syms so it can't be mocked. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Well, in fact only add comments to mark ifdef, else and endif sections. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Eric Blake 提交于
Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least the qemu implementation of virDomainGetXMLDesc, the use of the flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE prior to calling qemuDomainFormatXML. However, the use of VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write clients only. This patch treats the migratable flag as requiring the same permissions, rather than analyzing what might break if migratable xml no longer includes secret information. Fortunately, the information leak is low-risk: all that is gated by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password; but VNC passwords are already weak (FIPS forbids their use, and on a non-FIPS machine, anyone stupid enough to trust a max-8-byte password sent in plaintext over the network deserves what they get). SPICE offers better security than VNC, and all other secrets are properly protected by use of virSecret associations rather than direct output in domain XML. * src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC): Tighten rules on use of migratable flag. * src/libvirt-domain.c (virDomainGetXMLDesc): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1159219 Users might want to update startupPolicy via the virDomainUpdateDeviceFlags API too. This patch implements the feature on config layer. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 05 11月, 2014 2 次提交
-
-
由 Peter Krempa 提交于
The remote call actually doesn't free the arguments array so we leak memory in case a domain list is specified. As the remote domain list array consists only of stolen pointers from the actual domain objects it's sufficient just to free the array. Valgrind message: ==1081452== 64 bytes in 1 blocks are definitely lost in loss record 632 of 726 ==1081452== at 0x4C296D0: calloc (vg_replace_malloc.c:618) ==1081452== by 0x4EA5CB4: virAllocN (viralloc.c:191) ==1081452== by 0x505D21E: remoteConnectGetAllDomainStats (remote_driver.c:7785) ==1081452== by 0x50081AA: virDomainListGetStats (libvirt-domain.c:11080) ==1081452== by 0x155249: cmdDomstats (virsh-domain-monitor.c:2147) ==1081452== by 0x12FB73: vshCommandRun (virsh.c:1935) ==1081452== by 0x133FEB: main (virsh.c:3719)
-
由 Prerna Saxena 提交于
Domain memory elements such as max_balloon and cur_balloon are implemented as 'unsigned long long', whereas the 'memory' element in NUMA cells is implemented as 'unsigned int'. Use the same data type (unsigned long long) for 'memory' element in NUMA cells. Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
-
- 04 11月, 2014 7 次提交
-
-
由 Ján Tomko 提交于
A domain without a console quietly dies soon after start, because we try to set /dev/null as a controlling TTY 2014-10-30 15:10:59.705+0000: 1: error : lxcContainerSetupFDs:283 : ioctl(TIOCSCTTY) failed: Inappropriate ioctl for device Report an error early instead of trying to start it. https://bugzilla.redhat.com/show_bug.cgi?id=1155410
-
由 Ján Tomko 提交于
It fails after 30 seconds with this error: error : virDBusCall:1429 : error from service: CanSuspend: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Only probe for the power mgmt capabilities when driver is non-NULL. This speeds up domain startup by 30 seconds. https://bugzilla.redhat.com/show_bug.cgi?id=1159227
-
由 Martin Kletzander 提交于
Coverity found out the very obvious problem in the code. That is that virPidFileReleasePath() was called only if virPidFileAcquirePath() returned 0. But virPidFileAcquirePath() doesn't return only 0 on success, but the FD that needs to be closed. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Weiwei Li 提交于
In qemuMigrationFinish mig->nbd can not be initialized by qemuMigrationEatCookie without the QEMU_MIGRATION_COOKIE_NBD flag. That causes qemuMigrationStopNBDServer to return early without stopping the NBD server properly. Signed-off-by: NWeiwei Li <nuonuoli@tencent.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Chen Fan 提交于
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 Chen Fan 提交于
There was no check for 'nodeset' attribute in numatune-related elements. This patch adds validation that any nodeset specified does not exceed maximum host node. Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 Chen Fan 提交于
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
- 03 11月, 2014 11 次提交
-
-
由 Martin Kletzander 提交于
As discussed before, this simple script should help with debugging deadlocks, although there are still some caveats. RWLocks are not handled by this and if your deadlock if very racy, it may not lock up when running with this script due to the slowdown. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
When one domain is being undefined and at the same time started, for example, there is a possibility of a rare problem occuring. - Thread 1 does virDomainUndefine(), has the lock, checks that the domain is active and because it's not, calls virDomainObjListRemove(). - Thread 2 does virDomainCreate() and tries to lock the domain. - Thread 1 needs to lock domain list in order to remove the domain from it, but must unlock domain first (proper order is to lock domain list first and the domain itself second). - Thread 2 grabs the lock, starts the domain and releases the lock. - Thread 1 grabs the lock and removes the domain from list. With this patch: - qemuDomainRemoveInactive() creates a QEMU_JOB_MODIFY if that's possible, but since it must remove the domain from list either way, it continues even when starting the job failed. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1150505Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
When the list of domains is fetched and being printed, but in the meantime one domain was undefined before its status was fetched, the output then includes domain with "no state". With this patch, such domain is skipped over as consecutive 'virsh list --all' (or the same one ran a second later) wouldn't list it anyway. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Before: $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1 error: Unable to change blkio parameters error: invalid argument: unable to parse blkio device 'device_read_bytes_sec' '/dev/sda,-1' After: $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1 error: Unable to change blkio parameters error: invalid argument: invalid value '-1' for parameter 'device_read_bytes_sec' of device '/dev/sda' Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1131306Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Before: $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1 error: Unable to change blkio parameters error: invalid argument: unable to parse blkio device 'device_read_bytes_sec' '/dev/sda,-1' After: $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1 error: Unable to change blkio parameters error: invalid argument: invalid value '-1' for parameter 'device_read_bytes_sec' of device '/dev/sda' Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1131306Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
When daemon is killed right in the middle of probing a qemu binary for its capabilities, the qemu process is left running. Next time the daemon is starting, it cannot start the probing qemu process because the one that's already running does have the pidfile flock()'d. Reported-by: NWang Yufei <james.wangyufei@huawei.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This function is used to cleanup a pidfile doing whatever it takes, even killing the owning process. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
We were missing check for the fact that the storage driver was found and in case there is no vbox storage driver available, daemon raised the following error each start: error : virRegisterStorageDriver:592 : driver in virRegisterStorageDriver must not be NULL Fixing this makes the condition unified with networkDriver registration in vbox as well. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Particularly in qemuBuildNumaArgStr(), there was a need for the advice due to memory backing, which needs to know the nodeset it will be pinned to. With newer qemu this caused the following error when starting domain: error: internal error: Advice from numad is needed in case of automatic numa placement even when starting perfectly valid domain, e.g.: ... <vcpu placement='auto'>4</vcpu> <numatune> <memory mode='strict' placement='auto'/> </numatune> <cpu> <numa> <cell id='0' cpus='0' memory='524288'/> <cell id='1' cpus='1' memory='524288'/> </numa> </cpu> ... Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138545Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 John Ferlan 提交于
-
由 Daniel Veillard 提交于
- docs/news.html.in libvirt.spec.in: update for release - po/*.po*: fetched loclalization and regenerated
-
- 01 11月, 2014 6 次提交
-
-
由 Pavel Hrdina 提交于
Hotplugging and hotunplugging char devices is only supported through '-device' and the check for device capability should be independently. Coverity also complains about 'tmpChr->info.alias' could be NULL and we are dereferencing it but it somehow only in this case don't recognize that the value is set by 'qemuAssignDeviceChrAlias' so it's clearly false positive. Add sa_assert to make coverity happy. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Coverity is complaining about overwriting value in 'rc' variable without using the old value because it somehow doesn't recognize that the value is used by MACRO. The 'rc' variable is there only for checking return code so it's save to remove it and make coverity happy. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Ján Tomko 提交于
If both source adapters are specified by a parent address, just comparing the address is faster and catches even addresses that do not refer to valid adapters.
-
由 Pavel Hrdina 提交于
This macro seems to be defined only on linux/unix and it fails during mingw build. Its value is '16' (taken from net/if.h) so define it if it's not defined. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Eric Blake 提交于
Commit 6c9a8a49 (Oct 2014) exposed a long-standing issue on 32-bit machines: code related to virDomainSetMemoryParameters has always been documented as using a 64-bit limit, but it was implemented by calling virDomainParseMemory which enforced an 'unsigned long' limit. Since VIR_DOMAIN_MEMORY_PARAM_UNLIMITED capped to a long is -1, but virDomainParseScaledValue no longer accepts negative values, an attempt to use 2^53-1 as a hard memory limit started failing the testsuite. However, the problem with capping things artificially low has existed for much longer - ever since commits 4888f0fb and 2e22f23b (Mar 2012) switched internal tracking from 'unsigned long' to 'unsigned long long' (prior to that time, the cap was a side-effect of the choice of types). We _have_ to cap the balloon memory values, (no thanks to baked in 'unsigned long' of API such as virDomainSetMaxMemory or virDomainGetInfo with no counterpart API that guarantees 64-bit access to those numbers) but memory parameters have never needed the artificial limit. At any rate, the solution is to make the parser function gain a parameter, and only do the reduced 32-bit cap for the values that are constrained due to API. * src/conf/domain_conf.h (_virDomainMemtune): Add comments. * src/conf/domain_conf.c (virDomainParseMemory): Add parameter. (virDomainDefParseXML): Adjust callers. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 31 10月, 2014 4 次提交
-
-
由 weiwei li 提交于
commit 3e1e16aa (Use a port from the migration range for NBD as well) changed ndb port allocation from remotePorts to migrationPorts, but did not change the port releasing process, which makes an error when migrating several times (above 64): error: internal error: Unable to find an unused port in range 'migration' (49152-49215) https://bugzilla.redhat.com/show_bug.cgi?id=1159245Signed-off-by: NWeiwei Li <nuonuoli@tencent.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
由 Jim Fehlig 提交于
On error, libxlMakeDomBuildInfo() frees the caller-provided libxl_domain_build_info struct embedded in libxl_domain_config, causing a segfault Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f9c13020700 (LWP 40988)] (gdb) bt 0 0x00007f9c162f95b4 in free () from /lib64/libc.so.6 1 0x00007f9c0d0965ad in libxl_bitmap_dispose () from /usr/lib64/libxenlight.so.4.4 2 0x00007f9c0d0a73bf in libxl_domain_build_info_dispose () from /usr/lib64/libxenlight.so.4.4 3 0x00007f9c0d0a7974 in libxl_domain_config_dispose () from /usr/lib64/libxenlight.so.4.4 4 0x00007f9c0d2e00c5 in libxlDomainStart (driver=0x7f9c0400e4e0, vm=0x7f9c0412b0d0, start_paused=false, restore_fd=-1) at libxl/libxl_domain.c:1323 5 0x00007f9c0d2e1d4b in libxlDomainCreateXML (conn=0x7f9c000009a0,...) at libxl/libxl_driver.c:660 Remove the call to libxl_domain_build_info_dispose() from libxlMakeDomBuildInfo(). On error, callers will dispose the libxl_domain_config object, which in turn disposes the build info.
-
由 Jim Fehlig 提交于
With the introduction of the libxlDomainGetEmulatorType function, it is trivial to support a user-specfied <emulator> in the libxl driver. This patch is based loosely on David Scott's old patch to do the same https://www.redhat.com/archives/libvir-list/2013-April/msg02119.htmlSigned-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Ján Tomko 提交于
-