- 03 8月, 2015 2 次提交
-
-
由 Cao jin 提交于
s/virDomainFindBy/virDomainObjListFindBy/ Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
-
由 Luyao Huang 提交于
If cpuset is disabled or not available, it libvirt must not use it. Mainly for actions that do not need it and can use sched_setaffinity() or numa_membind() instead, because they will fail without good reason. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1244664Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
- 31 7月, 2015 2 次提交
-
-
由 Jiri Denemark 提交于
When stopping a domain on the destination host after a failed migration, we need to avoid reseting security labels since the domain is still running on the source host. While we were correctly doing so in some cases, there were still some paths which did this wrong. https://bugzilla.redhat.com/show_bug.cgi?id=1242904Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
In addition to checking the current asynchronous job qemuMigrationJobIsActive reports an error if the current job does not match the one we asked for. Let's just check the job directly since we are not interested in the error in qemuProcessHandleMonitorEOF. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 30 7月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
If destination libvirt doesn't support memory hotplug since all the support was introduced by adding new elements the destination would attempt to start qemu with an invalid configuration. The worse part is that qemu might hang in such situation. Fix this by sending a required migration feature called 'memory-hotplug' to the destination. If the destination doesn't recognize it it will fail the migration. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1248350
-
- 29 7月, 2015 1 次提交
-
-
由 Erik Skultety 提交于
Our atomic increment (virAtomicIntInc) uses (if available) gcc __sync_add_and_fetch builtin. In qemu driver though, we'd profit more from __sync_fetch_and_add builtin. To keep it simplistic, this patch adjusts qemu driver initialization rather than adding a new atomic increment macro.
-
- 27 7月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Commit d506a51a meant to check for QEMU_CAPS_DRIVE_IOTUNE_MAX, but checked for QEMU_CAPS_DRIVE_IOTUNE instead. That's clearly visible from the diff, but it got in. Because of that, we were supplying information unknown for QEMU if it wasn't new enough and we couldn't even properly handle the error, leading to "Unexpected error". Also iops_size came at the same time with all the other "_max" options, so check whether we're not setting that either if QEMU_CAPS_DRIVE_IOTUNE_MAX is not supported. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1224053Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 25 7月, 2015 1 次提交
-
-
由 Laine Stump 提交于
This loop occurs just after we've assured that all devices that require a PCI device have been assigned and all necessary PCI controllers have been added. It is the perfect place to add other potentially auto-generated PCI controller attributes that are dependent on the controller's PCI address (upcoming patch). There is a convenient loop through all controllers at the end of the function, but the patch to add new functionality will be cleaner if we first rearrange that loop a bit. Note that the loop originally was accessing info.addr.pci.bus prior to determining that the pci part of the object was valid. This isn't dangerous in any way, but seemed a bit ugly, so I fixed it.
-
- 24 7月, 2015 2 次提交
-
-
由 Cao jin 提交于
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
-
由 Martin Kletzander 提交于
This reverts commit 7b401c3b. Until libvirt is able to differentiate whether heads='1' is just a leftover from previous libvirt or whether that's added by user on purpose and also whether the domain was started with the support for qxl's max_outputs, we cannot incorporate this patch into the tree due to compatibility reasons. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 22 7月, 2015 2 次提交
-
-
由 Luyao Huang 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1245476 We won't return the errno after commit 0d7f45ae, and the more clearly error will be set in the code in vircgroup*. Also We will always report error "Operation not permitted", because the return is -1. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Peter Krempa 提交于
The scope name, even according to our docs is "machine-$DRIVER\x2d$VMNAME.scope" virSystemdMakeScopeName would use the resource partition name instead of "machine-" if it was specified thus creating invalid scope paths. This makes libvirt drop cgroups for a VM that uses custom resource partition upon reconnecting since the detected scope name would not match the expected name generated by virSystemdMakeScopeName. The error is exposed by the following log entry: debug : virCgroupValidateMachineGroup:302 : Name 'machine-qemu\x2dtestvm.scope' for controller 'cpu' does not match 'testvm', 'testvm.libvirt-qemu' or 'machine-test-qemu\x2dtestvm.scope' for a "/machine/test" resource and "testvm" vm. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1238570
-
- 21 7月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Few parts of the code looked at the current progress of and assumed that a two phase blockjob is in the _READY state as soon as the progress reached 100% (info.cur == info.end). In current versions of qemu this assumption is invalid and qemu exposes a new flag 'ready' in the query-block-jobs output that is set to true if the job is actually finished. This patch adds internal data handling for reading the 'ready' flag and acting appropriately as long as the flag is present. While this still doesn't fix the virsh client problem with two phase block jobs and the --pivot option, it at least improves the error message: $ virsh blockcommit --wait --verbose vm vda --base vda[1] --active --pivot Block commit: [100 %]error: failed to pivot job for disk vda error: internal error: unable to execute QEMU command 'block-job-complete': The active block job for device 'drive-virtio-disk0' cannot be completed to $ virsh blockcommit --wait --verbose VM vda --base vda[1] --active --pivot Block commit: [100 %]error: failed to pivot job for disk vda error: block copy still active: disk 'vda' not ready for pivot yet
-
- 20 7月, 2015 2 次提交
-
-
由 Martin Kletzander 提交于
If one calls update-device with information that is not updatable, libvirt reports success even though no data were updated. The example used in the bug linked below uses updating device with <boot order='2'/> which, in my opinion, is a valid thing to request from user's perspective. Mainly since we properly error out if user wants to update such data on a network device for example. And since there are many things that might happen (update-device on disk basically knows just how to change removable media), check for what's changing and moreover, since the function might be usable in other drivers (updating only disk path is a valid possibility) let's abstract it for any two disks. We can't possibly check for everything since for many fields our code does not properly differentiate between default and unspecified values. Even though this could be changed, I don't feel like it's worth the complexity so it's not the aim of this patch. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1007228
-
由 Frediano Ziglio 提交于
Allows to specify maximum number of head to QXL driver. Actually can be a compatiblity problem as heads in the XML configuration was set by default to '1'. Signed-off-by: NFrediano Ziglio <fziglio@redhat.com>
-
- 15 7月, 2015 3 次提交
-
-
由 Boris Fiuczynski 提交于
For s390-ccw-virtio machines the default bus type is set to ccw. Specifing an address element allows to override the default. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJason J. Herne <jjherne@us.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
-
由 Boris Fiuczynski 提交于
Adding the recently in qemu added 9pfs support for virtio-ccw. Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com> Reviewed-by: NJason J. Herne <jjherne@us.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
-
由 Michal Privoznik 提交于
If we are migrating to an UNIX socket, we accept() a connection from qemu and use that FD to set up a tunnel. However, the FD is not closed as often as it should be. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 14 7月, 2015 7 次提交
-
-
由 Peter Krempa 提交于
In commit 641a145d I've added code that resets the balloon memory value to full size prior to resuming the vCPUs since the size certainly was not reduced at that point. Since qemuProcessStart is used also in code paths with already booted up guests (migration, save/restore) the assumption is not entirely true since the guest might already been running before. This patch adds a function that queries the monitor rather than using the full size since a balloon event would not be reissued in case we are recovering a saved migration state. Additionally the new function is used also when reconnecting to a VM after libvirtd restart since we might have missed a few balloon events while libvirtd was not running.
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1232663 In one of my previous ptaches (bcd9a564) I've tried to fix the problem that we blindly assumed strict NUMA mode for guests. This led to several problems like us pinning a domain onto a nodeset via libnuma among with CGroups. Once the nodeset was changed by user, well, it did not result in desired effect. See the original commit for more info. But, the commit I wrote had a bug: when NUMA parameters are changed on a running domain we require domain to be strictly pinned onto a nodeset. Due to a typo a condition was mis-evaluated. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Add the sysfs_prefix argument to the call to allow for setting the path for tests to something other than SYSFS_SYSTEM_PATH.
-
由 John Ferlan 提交于
Add the sysfs_prefix argument to the call to allow for setting the path for tests to something other than SYSFS_CPU_PATH which is a derivative of SYSFS_SYSTEM_PATH Use cpupath for nodeCapsInitNUMAFake and remove SYSFS_CPU_PATH
-
由 John Ferlan 提交于
Add the sysfs_prefix argument to the call to allow for setting the path for tests to something other than SYSFS_SYSTEM_PATH.
-
由 John Ferlan 提交于
Add the sysfs_prefix argument to the call to allow for setting the path for tests to something other than SYSFS_SYSTEM_PATH.
-
由 John Ferlan 提交于
Add the sysfs_prefix argument to the call to allow for setting the path for tests to something other than SYSFS_SYSTEM_PATH.
-
- 13 7月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
After Jirka's migration patches libvirt is listening on migration events from qemu instead of actively polling on the monitor. There is, however, a little regression (introduced in 6d2edb6a). The problem is, the current status of migration job is updated in qemuProcessHandleMigrationStatus if and only if migration job was started. But eventually every asynchronous job may result in migration. Therefore, since this job is not strictly a migration job, internal state was not updated and later checks failed: virsh # save fedora22 /tmp/fedora22_ble.save error: Failed to save domain fedora22 to /tmp/fedora22_ble.save error: operation failed: domain save job: is not active Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 10 7月, 2015 14 次提交
-
-
由 Jiri Denemark 提交于
When QEMU exits on destination during migration, the source reports either success (if the failure happened at the very end) or unhelpful "unexpectedly failed" error message. However, the Finish API called on the destination may report a real error so let's use it instead of the generic one. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
virDomainMigrateFinish* APIs were unfortunately designed to return the pointer to the domain on destination and NULL on error. This looks OK in normal cases but the same API is also called when we know migration failed and thus we expect Finish to return NULL even if it actually did all it was supposed to do without any error. The call is defined to return nonnull domain pointer over RPC, which means returning NULL will always result in an error being send. If this was not in fact an error, the API itself wouldn't set anything to the thread local virError, which makes the RPC layer come up with it's own "Library function returned error but did not set virError" error. This is quite confusing and also hard to detect by the caller. This patch adds a special error code which can be used to check that Finish successfully aborted migration. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
If QEMU fails during incoming migration, the domain disappears including a possibly useful error message read from QEMU log file. Let's remember the error in virQEMUDriver so that Finish can report more than just "no such domain". Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Libvirt's error messages do not end with a LF. However, when reading the error from QEMU log, we would read the LF from the log and keep it in the message. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Since we already support the MIGRATION event, we just need to make sure the domain condition is signalled whenever a p2p connection drops or the domain is paused due to IO error and we can avoid waking up every 50 ms to check whether something happened. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
We don't need to call query-migrate every 50ms when we get the current migration state via MIGRATION event. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
When QEMU supports migration events the qemuDomainJobInfo structure will no longer be updated with migration statistics. We have to enter a job and explicitly ask QEMU every time virDomainGetJob{Info,Stats} is called. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Even if QEMU supports migration events it doesn't send them by default. We have to enable them by calling migrate-set-capabilities. Let's enable migration events everytime we can and clear QEMU_CAPS_MIGRATION_EVENT in case migrate-set-capabilities does not support events. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Thanks to Juan's work QEMU finally emits an event whenever migration state changes. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Guido Günther 提交于
This fixes CC qemu/libvirt_driver_qemu_impl_la-qemu_conf.lo qemu/qemu_conf.c: In function 'qemuRemoveSharedDevice': qemu/qemu_conf.c:1384:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
-
由 Pavel Hrdina 提交于
Some guests lock the tray and QEMU eject command will simply fail to eject the media. But the guest OS can handle this attempt to eject the media and can unlock the tray and open it. In this case, we should try again to actually eject the media. If the first attempt fails to detect a tray_open we will fail with error, from monitor. If we receive that event, we know, that the guest properly reacted to the eject request, unlocked the tray and opened it. In this case, we need to run the command again to actually eject the media from the device. The reason to call it again is, that QEMU doesn't wait for the guest to react and report an error, that the tray is locked. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1147471Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Modify the eject monitor functions to parse the return code and detect, whether the error contains "is locked" to report this type of failure to upper layers. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
There are multiple consumers for the domain condition and we should always wake them all. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-