- 11 3月, 2015 3 次提交
-
-
由 Michael Chapman 提交于
Undefining a running, autostarted domain removes the autostart link, but dom->autostart is not cleared. If the domain is subsequently redefined, libvirt thinks it is already autostarted and will not create the link even if requested: # virsh dominfo example | grep Autostart Autostart: enable # ls /etc/libvirt/qemu/autostart/example.xml /etc/libvirt/qemu/autostart/example.xml # virsh undefine example Domain example has been undefined # virsh define example.xml Domain example defined from example.xml # virsh dominfo example | grep Autostart Autostart: enable # virsh autostart example Domain example marked as autostarted # ls /etc/libvirt/qemu/autostart/example.xml ls: cannot access /etc/libvirt/qemu/autostart/example.xml: No such file or directory This commit ensures dom->autostart is cleared whenever the config and autostart link (if present) are removed. The bridge network driver cleared this flag itself in networkUndefine. This commit moves this into virNetworkDeleteConfig for symmetry with virDomainDeleteConfig, and to ensure it is not missed in future network drivers. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Luyao Huang 提交于
Error messages are already set in all code paths returning -1 from networkGetNetworkAddress, so we don't want to overwrite them. Signed-off-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
When creating qemu capabilities, a dummy virDomainObj is created just because our monitor code expects that. However, the object is created locked already. Then, under cleanup label, we simply unref the object which results in whole domain object to be disposed. The object lock is destroyed subsequently, but hey - it's still locked: ==24845== Thread #14's call to pthread_mutex_destroy failed ==24845== with error code 16 (EBUSY: Device or resource busy) ==24845== at 0x4C3024E: pthread_mutex_destroy (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==24845== by 0x531F72E: virMutexDestroy (virthread.c:83) ==24845== by 0x5302977: virObjectLockableDispose (virobject.c:237) ==24845== by 0x5302A89: virObjectUnref (virobject.c:265) ==24845== by 0x1DD37866: virQEMUCapsInitQMP (qemu_capabilities.c:3397) ==24845== by 0x1DD37CC6: virQEMUCapsNewForBinary (qemu_capabilities.c:3481) ==24845== by 0x1DD381E2: virQEMUCapsCacheLookup (qemu_capabilities.c:3609) ==24845== by 0x1DD30F8A: virQEMUCapsInitGuest (qemu_capabilities.c:744) ==24845== by 0x1DD31889: virQEMUCapsInit (qemu_capabilities.c:1020) ==24845== by 0x1DD7DD36: virQEMUDriverCreateCapabilities (qemu_conf.c:888) ==24845== by 0x1DDC57C0: qemuStateInitialize (qemu_driver.c:803) ==24845== by 0x53DC743: virStateInitialize (libvirt.c:777) ==24845== Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 3月, 2015 6 次提交
-
-
由 Chen Fan 提交于
in virDomainFSInfoFree(), don't free the virDomainFSInfo data. ==10670== 80 bytes in 2 blocks are definitely lost in loss record 576 of 793 ==10670== at 0x4A06BC3: calloc (vg_replace_malloc.c:618) ==10670== by 0x509DEBD: virAlloc (viralloc.c:144) ==10670== by 0x19FBD558: qemuAgentGetFSInfo (qemu_agent.c:1837) ==10670== by 0x1A03CF91: qemuDomainGetFSInfo (qemu_driver.c:19238) Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
-
由 Ján Tomko 提交于
Test the whole range in testBit, not just the first bit.
-
由 Ján Tomko 提交于
Instead of finding the next clear bit by calling virBitmapGetBit in a loop, use the virBitmapNextClearBit helper.
-
由 Laine Stump 提交于
Commit 4bbe1029 fixed a problem in commit f7afeddc by moving the call to virNetDevGetIndex() to a location common to all interface types (so that the nicindex array would be filled in for macvtap as well as tap interfaces), but the location was *too* common, as the original call to virNetDevGetIndex() had been in a section qualified by "if (cfg->privileged)". The result was that the "fixed" libvirtd would try to call virNetDevGetIndex() even for session mode libvirtd, and end up failing with the log message: Unable to open control socket: Operation not permitted To remedy that, this patch qualifies the call to virNetDevGetIndex() in its new location with cfg->privileged. This resolves https://bugzilla.redhat.com/show_bug.cgi?id=1198244
-
由 Michal Privoznik 提交于
As of bba93d40 all of our RPC objects are derived from virObjectLockable. However, during rewrite some errors sneaked in. For instance, the dispose functions to virNetClient and virNetServerClient objects were not only freeing allocated memory, but unlocking themselves. This is wrong. Object should never disappear while locked. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Hrdina 提交于
To prevent a confusion about missing chardev argument in qemu command line add a note about that behavior into documentation. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1129198Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 09 3月, 2015 23 次提交
-
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1127045Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1127045Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1127045Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Michal Privoznik 提交于
Now that all the code uses accessors, don't expose the structure anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Well, one day this will be self-locking object, but not today. But lets prepare the code for that! Moreover, virNetworkObjListFree() is no longer needed, so turn it into virNetworkObjListDispose(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The API will iterate over the list of network object and remove desired ones from it. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
An accessor following pattern laid out by virDomainObjList* APIs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
An accessor following pattern laid out by virDomainObjList* APIs. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This API will be used in the future to call passed callback over each network object in the list. It's slightly different to its virDomainObjListForEach counterpart, because virDomainObjList uses a hash table to store domain object, while virNetworkObjList uses an array. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
Commit v1.2.4-52-gda879e59 fixed issues with domains started before sanlock driver was enabled by checking whether a running domain is registered with sanlock and if it's not, sanlock driver is basically ignored for the domain. However, it was checking this even for domain which has just been started and no sanlock_* API was called for them yet. This results in cmd 9 target pid 2135544 not found error messages to appear in sanlock.log whenever we start a new domain. This patch avoids this useless check for freshly started domains. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virLockManager*New APIs are never called with VIR_LOCK_MANAGER_USES_STATE. Moreover, lockd driver does not maintain any state that would need to be transferred during migration and thus it should not mention VIR_LOCK_MANAGER_USES_STATE at all. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Pavel Hrdina 提交于
Commit 5aee81a0 introduced a new test for disk-serial. The test fails on i686 arch because there is no need to add "-cpu qemu32" to command line. To fix the test update emulator in XML to "/usr/bin/qemu" so we don't add the "-cpu qemu32" to command while running the test on i686 or x86_64 host. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 John Ferlan 提交于
Follow-up to the IOThread review on CPU affinity map manipulation: http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html indicates that the GetEmulatorPinInfo could use similar algorithm adjustments which is what this patch does.
-
由 John Ferlan 提交于
Follow-up to the IOThread review on CPU affinity map manipulation: http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html indicates that the GetVcpuPinInfo could use similar algorithm adjustments which is what this patch does.
-
由 John Ferlan 提交于
By adding a call and check of return of virBitmapToData to the IOThreads code, my Coverity checker lets me know qemuDomainHelperGetVcpus also needs to check the status...
-
由 John Ferlan 提交于
Based on review: http://www.redhat.com/archives/libvir-list/2015-March/msg00294.html Adjust how the cpumap and cpumaplen to be returned are generated
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
-
由 Martin Kletzander 提交于
We don't usually do tests purely for one change, but one change was special because when users will migrate to OVMF/AAVMF, commit 18f9f69b makes their lives easier by allowing them to interleave <type/> inside <os/>. It would be nice of us to keep the possibility of them pasting the loader and nvram elements wherever it is valid, hence this test. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Commit 3e4b783e fixed an issue with RNG schema where this address type was missing, this commit adds a test for it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 06 3月, 2015 8 次提交
-
-
由 Michal Privoznik 提交于
We have something like pvpanic device. However, in some cases it does not have any address assigned, in which case we produce this ugly XML (still valid though): <devices> <emulator>/usr/bin/qemu</emulator> ... <panic> </panic> </devices> Lets format "<panic/>" instead. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Daniel P. Berrange 提交于
Delete .po files which contain zero translated strings. Refresh the .pot file and pull down latest translations from Zanata. When refreshing the libvirt.pot, it can be pushed to zanata and .po files resynchonized using # cd po # rm libvirt.pot # make libvirt.pot # zanata-cli push # zanata-cli pull Note there is no need for 'make update-po', as long as you do a zanata push, immediately followed by zanata pull, as the Zanata server will ensure the .po files downloaded match the just pushed .pot file. Note at time of writing, it is strongly recommended to only use the zanata Java client binary (zanata-cli), and not the python client binary (zanata). This is because the moderately large size of the libvirt pot file is causing errors when the python client tries to push, which have been known to result in the loss of all translations on the server, as well as also preventing uploading of .po files themselves :-(
-
由 John Ferlan 提交于
Add the 'iothreadsinfo' command to display IOThread Info data. Allow for [--live] or [--config] options in order to display live or config data for an active domain. $ virsh iothreadsinfo --help NAME iothreadsinfo - view domain IOThreads SYNOPSIS iothreadsinfo <domain> [--config] [--live] [--current] DESCRIPTION Returns basic information about the domain IOThreads. OPTIONS [--domain] <string> domain name, id or uuid --config affect next boot --live affect running domain --current affect current domain An active domain may return: $ virsh iothreads $dom IOThread ID CPU Affinity --------------------------------------------------- 1 2 2 3 3 0 $ echo $? 0 For domains which don't have IOThreads the following is returned: $ virsh iothreads $dom No IOThreads found for the domain $ echo $? 0 For domains which are not running the following is returned: $ virsh iothreads $dom --live error: Unable to get domain IOThreads information error: Requested operation is not valid: domain is not running $ echo $? 1 Editing a domains configuration and modifying the iothreadpin data for thread 3 from nothing provided to setting a cpuset of '0-1' and then displaying using --config would display: $ virsh iothreads f18iothr --config IOThread ID CPU Affinity ---------------------------- 1 2 2 3 3 0-1 $ Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Depending on the flags passed, either attempt to return the active/live IOThread data for the domain or the config data. The active/live path will call into the Monitor in order to get the IOThread data and then correlate the thread_id's returned from the monitor to the currently running system/threads in order to ascertain the affinity for each iothread_id. The config path will map each of the configured IOThreads and return any configured iothreadspin data Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Implement the remote plumbing for virDomainGetIOThreadsInfo Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 John Ferlan 提交于
Add virDomainGetIOThreadInfo in order to return a list of virDomainIOThreadInfoPtr structures which list the IOThread ID and the CPU Affinity map for each IOThread for the domain. For an active domain, the live data will be returned, while for an inactive domain, the config data will be returned. The API supports either the --live or --config flag, but not both. Also added virDomainIOThreadsInfoFree in order to free the cpumap and the IOThreadInfo structure. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Pavel Hrdina 提交于
There was a mess in the way how we store unlimited value for memory limits and how we handled values provided by user. Internally there were two possible ways how to store unlimited value: as 0 value or as VIR_DOMAIN_MEMORY_PARAM_UNLIMITED. Because we chose to store memory limits as unsigned long long, we cannot use -1 to represent unlimited. It's much easier for us to say that everything greater than VIR_DOMAIN_MEMORY_PARAM_UNLIMITED means unlimited and leave 0 as valid value despite that it makes no sense to set limit to 0. Remove unnecessary function virCompareLimitUlong. The update of test is to prevent the 0 to be miss-used as unlimited in future. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1146539Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
The first one is to truncate the memory limit to VIR_DOMAIN_MEMORY_PARAM_UNLIMITED if the value is greater and the second one is to decide whether the memory limit is set or not, unlimited means that it's not set. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-