- 10 11月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
If mlock is required either due to use of VFIO hostdevs or due to the fact that it's enabled it needs to be tweaked prior to adding new memory or after removing a module. Add a helper to determine when it's necessary and reuse it both on hotplug and hotunplug. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1273491
-
由 Peter Krempa 提交于
New function qemuDomainGetMlockLimitBytes will now handle the calculation so that it unifies the logic to one place and allows later reuse.
-
- 05 11月, 2015 2 次提交
-
-
由 Peter Krempa 提交于
The code reported that a migration flag is unsupported but didn't jump to the error label. Probably an oversight in commit f88af9dc that introduced the flag checking.
-
由 Peter Krempa 提交于
Since the flag was not enabled when 'eating' the migration cookie, libvirt reported a bogus error when memory hotplug was enabled: unsupported migration cookie feature memory-hotplug The error was ignored though due to a bug in the code so it slipped through testing. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1278404
-
- 04 11月, 2015 5 次提交
-
-
由 Jiri Denemark 提交于
nodeset should be freed in both success and failure paths. While tmppath is freed immediately after it's consumed, moving it from error to cleanup label is a bit more consistent and robust. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Remove code duplication by moving common cleanup code in a dedicated label. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Generally, we use "ret" variable for storing the value we are going to return at the and of a function, but this is not the case in qemuProcessStart. Let's rename "ret" as "rv". Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Current "cleanup" label is only used in error path, thus it should rather be called "error". Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart was passing char * migrateFrom as the third argument to qemuPrepareNVRAM. We should explicitly convert the pointer to bool which is what the function expects. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 29 10月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1270715 Commit id '9deb96f9' removed the code to fetch the nodeset from the CpusetMems cgroup for a running vm in favor of using the return from virDomainNumatuneFormatNodeset introduced by commit id '43b67f2e'. However, that API will return the value of the passed 'auto_nodeset' when placement is VIR_DOMAIN_NUMATUNE_PLACEMENT_AUTO, which happens to be NULL. Since commit id 'c74d58ad' started using priv->autoNodeset in order to manage the auto placement value during qemuProcessStart, it should be passed along in order to return the correct value if the domain requests the auto placement. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 27 10月, 2015 1 次提交
-
-
由 Luyao Huang 提交于
In commit f41be296, we moved vm->persistent check into qemuDomainRemoveInactive, but we didn't change the vm->persistent before call qemuDomainRemoveInactive in some place before and just call it to remove the inactive vm. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 26 10月, 2015 4 次提交
-
-
由 Andrea Bolognani 提交于
This calls the PCI-, USB- and SCSI-specific functions just like qemuHostdev{Prepare,ReAttach}DomainDevices() already do, and was the missing piece for the qemuHostdev API to nicely mirror the virHostdev API. Update qemuProcessReconnect() to use the new function.
-
由 Andrea Bolognani 提交于
Adopt the same names used for virHostdevUpdateActive*Devices() for consistency's sake and to make it easier to jump between the two. No functional changes.
-
由 Andrea Bolognani 提交于
Adopt the same names used for virHostdevReAttach*Devices() for consistency's sake and to make it easier to jump between the two. No functional changes.
-
由 Andrea Bolognani 提交于
Adopt the same names used for virHostdevPrepare*Devices() for consistency's sake and to make it easier to jump between the two. No functional changes.
-
- 21 10月, 2015 1 次提交
-
-
由 Ishmanpreet Kaur Khera 提交于
We have macros for both positive and negative string matching. Therefore there is no need to use !STREQ or !STRNEQ. At the same time as we are dropping this, new syntax-check rule is introduced to make sure we won't introduce it again. Signed-off-by: NIshmanpreet Kaur Khera <khera.ishman@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 16 10月, 2015 4 次提交
-
-
由 Shivaprasad G Bhat 提交于
Tunnelled migration can hang if the destination qemu exits despite all the ABI checks. This happens whenever the destination qemu exits before the complete transfer is noticed by source qemu. The savevm state checks at runtime can fail at destination and cause qemu to error out. The source qemu cant notice it as the EPIPE is not propogated to it. The qemuMigrationIOFunc() notices the stream being broken from virStreamSend() and it cleans up the stream alone. The qemuMigrationWaitForCompletion() would never get to 100% transfer completion. The qemuMigrationWaitForCompletion() never breaks out as well since the ssh connection to destination is healthy, and the source qemu also thinks the migration is ongoing as the Fd to which it transfers, is never closed or broken. So, the migration will hang forever. Even Ctrl-C on the virsh migrate wouldn't be honoured. Close the source side FD when there is an error in the stream. That way, the source qemu updates itself and qemuMigrationWaitForCompletion() notices the failure. Close the FD for all kinds of errors to be sure. The error message is not copied for EPIPE so that the destination error is copied instead later. Note: Reproducible with repeated migrations between Power hosts running in different subcores-per-core modes. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1249981 When qemuDomainPinIOThread was added in commit id 'fb562614', a check for the IOThread capability was not needed since a check for iothreadpids covered the condition where the support for IOThreads was not present. The iothreadpids array was only created if qemuProcessDetectIOThreadPIDs was able to query the monitor for IOThreads. It would only do that if the QEMU_CAPS_OBJECT_IOTHREAD capability was set. However, when iothreadids were added in commit id '8d4614a5' and the check for iothreadpids was replaced by a search through the iothreadids[] array for the matching iothread_id that left open the possibility that an iothreadids[] array was defined, but the entries essentially pointed to elements with only the 'iothread_id' defined leaving the 'thread_id' value of 0 and eventually the cpumap entry of NULL. This was because, the original IOThreads commit id '72edaae7' only checked if IOThreads were defined and if the emulator had the IOThreads capability, then IOThread objects were added at startup. The "capability failure" check was only done when a disk was assigned to an IOThread in qemuCheckIOThreads. This was because the initial implementation had no way to dynamically add IOThreads, but it was possible to dynamically add a disk to the domain. So the decision was if the domain supported it, then add the IOThread objects. Then if a disk with an IOThread defined was added, it could check the capability and fail to add if not there. This just meant the 'iothreads' value was essentially ignored. Eventually commit id 'a27ed6e7' allowed for the dynamic addition and deletion of IOThread objects. So it was no longer necessary to generate IOThread objects to dynamically attach a disk to. However, the startup and disk check code was not modified to reflect this. This patch will move the capability failure check to when IOThread objects are being added to the command line. Thus a domain that has IOThreads defined will not be started if the emulator doesn't support the capability. This means when qemuCheckIOThreads is called to add a disk, it's no longer necessary to check the capability. Instead the code can use the IOThreadFind call to indicate that the IOThread doesn't exist. Finally because it could be possible to have a domain running with the iothreadids[] defined prior to this change if libvirtd is restarted each having mostly empty elements, qemuProcessDetectIOThreadPIDs will check if there are niothreadids when the QEMU_CAPS_OBJECT_IOTHREAD capability check fails and remove the elements and array if it exists. With these changes in place, it turns out the cputune-numatune test was failing because the right bit wasn't set in the test. So used the opportunity to fix that and create a test that would expect to fail with some sort of iothreads defined and used, but not having the correct capability.
-
由 John Ferlan 提交于
If there are no IOThreads defined, no sense making other checks
-
由 John Ferlan 提交于
Although theoretically both should be the same value, the niothreadids should be used in favor of iothreads when performing comparisons. This leaves the iothreads as a purely numeric value to be saved in the config file. The one exception to the rule is virDomainIOThreadIDDefArrayInit where the iothreadids are being generated from the iothreads count since iothreadids were added after initial iothreads support.
-
- 09 10月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
The internal representation of a JSON array counts the items in size_t. However, for some reason, when asking for the count it's reported as int. Firstly, we need the function to return a signed type as it's returning -1 on an error. But, not every system has integer the same size as size_t. Therefore, lets return ssize_t. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 08 10月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Coverity notices that net->ifname is potentially referenced after a VIR_FREE(). Since the net->ifname will eventually be free'd during virDomainDefFree when calling virDomainNetDefFree, let's just that processing take care the free. Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 07 10月, 2015 7 次提交
-
-
由 Michal Privoznik 提交于
So imagine you want to crate new security manager: if (!(mgr = virSecurityManagerNew("selinux", "QEMU", false, true, false, true))); Hard to parse, right? What about this: if (!(mgr = virSecurityManagerNew("selinux", "QEMU", VIR_SECURITY_MANAGER_DEFAULT_CONFINED | VIR_SECURITY_MANAGER_PRIVILEGED))); Now that's better! This is what the commit does. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Andrea Bolognani 提交于
Two #define lines introduced by b527aa09 did not respect the indentation rules, thus breaking syntax-check.
-
由 Andrea Bolognani 提交于
This gets rid of the partially enforced alignment and makes it less likely for a bogus value to be introduced in the enumeration. Capabilities are divided in five-element groups for better readability. Use #define for QEMU_CAPS_NET_NAME and QEMU_CAPS_HOST_NET_ADD, both of which are aliases for QEMU_CAPS_0_10.
-
由 Peter Krempa 提交于
qemuMigrationIsAllowed would disallow offline migration if the VM contained host devices or memory modules. Since during offline migration we don't transfer any state we can safely migrate VMs with such configuration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1265049
-
由 Peter Krempa 提交于
Use the migration @flags for checking various migration aspects rather than picking them out as booleans. Document the new semantics in the function header.
-
由 Peter Krempa 提交于
Now that qemuMigrationIsAllowed is always called with @vm, we can drop the @def argument and simplify the control flow. Additionally the comment is invalid so drop it.
-
由 Peter Krempa 提交于
Extract the hostdev check from qemuMigrationIsAllowed into a separate function since that is the only part that needs to be done in the v2 migration protocol prepare phase on the destination. All other checks were added when the v3 protocol existed so they don't need to be extracted. This change will allow to drop the @def argument for qemuMigrationIsAllowed and further simplify the function.
-
- 06 10月, 2015 5 次提交
-
-
由 Jiri Denemark 提交于
Even though QEMU on the source host reports completed migration and thus we move to the Finish phase, QEMU on the destination host may still be processing migration data. Thus before we can start guest CPUs on the destination, we have to wait for a completed migration event. https://bugzilla.redhat.com/show_bug.cgi?id=1265902Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
With new QEMU which supports migration events, qemuMigrationCheckJobStatus needs to explicitly query QEMU for migration statistics once migration is completed to make sure the caller sees up-to-date statistics with both old and new QEMU. However, some callers are not interested in the statistics at all and once we start waiting for a completed migration on the destination host too, checking the statistics would even fail. Let's push the decision whether to update the statistics or not to the caller. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The function already has two bool parameters and we will need to add a new one. Let's switch to flags to make the callers readable. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The destination host gets detailed statistics about the current migration form the source host via migration cookie and copies them to the domain object so that they can be queried using virDomainGetJobStats. However, we should only copy statistics to the domain object when migration finished successfully. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Even if we are migrating a domain with VIR_MIGRATE_PAUSED flag set, we should still update the total time of the migration. Updating downtime doesn't hurt either, even though we don't actually start guest CPUs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 05 10月, 2015 3 次提交
-
-
由 Andrea Bolognani 提交于
qemu-kvm can be used to run ppc64 guests on ppc64le hosts and vice versa, since the hardware is actually the same and the endianness is chosen by the guest kernel. Up until now, however, libvirt didn't allow the use of qemu-kvm to run guests if their endianness didn't match the host's. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1267882
-
由 Peter Krempa 提交于
Rename the function to virDomainDefCheckDuplicateDiskInfo and make it check disk serials too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1245013
-
由 Peter Krempa 提交于
Since we'd disallow migration of a guest that would have possibly invalid config but still be able to work, relax the WWN check to be performed only on new starts of the VM.
-
- 02 10月, 2015 3 次提交
-
-
由 Martin Kletzander 提交于
We are using memory-backing-file even when it's not needed, for example if user requests hugepages for memory backing, but does not specify any pagesize or memory node pinning. This causes migrations to fail when migrating from older libvirt that did not do this. So similarly to commit 7832fac8 which does it for memory-backend-ram, this commit makes is more generic and backend-agnostic, so the backend is not used if there is no specific pagesize of hugepages requested, no nodeset the memory node should be bound to, no memory access change required, and so on. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1266856Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
So since the introduction of the memory-backend-file object until now we only added '-mem-path' for non-NUMA guests and we used the parameters of the memory-backend-file object to specify the path to the hugetlbfs mount. But hugepages can be also used without memory-backend-file object, as it used to be before its introduction. Let's just get this part of the code back and properly append the '-mem-path' for NUMA guests as well, but only when the memory backend is not needed. This parameter is already being applied when no numa is requested and because we still use memory-object-file unconditionally for hugepage-backed NUMA guests, this should not fire until later. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
That function is called qemuBuildMemPathStr() and will be used in other places in the future. The change in the test suite is proper due to the fact that -mem-prealloc makes only sense with -mem-path (from qemu documentation -- html/qemu-doc.html). Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-