- 25 11月, 2015 4 次提交
-
-
由 Dmitry Andreev 提交于
-
由 Guido Günther 提交于
This adds the qemu binaries as of 1.2.4 in Debian. It also removes a duplicate sparc64 entry.
-
由 Laine Stump 提交于
A PCI device may have the capability to setup virtual functions (VFs) but have them currently all disabled. Prior to this patch, if that was the case the the node device XML for the device wouldn't report any virtual_functions capability. With this patch, if a file called "sriov_totalvfs" is found in the device's sysfs directory, its contents will be interpreted as a decimal number, and that value will be reported as "maxCount" in a capability element of the device's XML, e.g.: <capability type='virtual_functions' maxCount='7'/> This will be reported regardless of whether or not any VFs are currently enabled for the device. NB: sriov_numvfs (the number of VFs currently active) is also available in sysfs, but that value is implied by the number of items in the list that is inside the capability element, so there is no reason to explicitly provide it as an attribute. sriov_totalvfs and sriov_numvfs are available in kernels at least as far back as the 2.6.32 that is in RHEL6.7, but in the case that they simply aren't there, libvirt will behave as it did prior to this patch - no maxCount will be displayed, and the virtual_functions capability will be absent from the device's XML when 0 VFs are enabled.
-
由 Laine Stump 提交于
Report the maximum possible number of VFs for an SRIOV PF, like this: <capability type='virtual_functions' maxCount='7'> ... </capability> I've just discovered that the virtual_functions and physical_functions capabilities are not supported in the virNodeDeviceParse functions, only in virNodeDeviceFormat (I suppose because they are only reported, not set from XML). This should probably be remedied, but is less immediately useful than the current patch.
-
- 24 11月, 2015 9 次提交
-
-
由 Peter Krempa 提交于
The return value has non-obvious semantics. Document it.
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
The checked predicate is a deduction from the following checks: 1) maximum cpu id is checked for every parsed <vcpusched> element 2) the resulting bitmaps are checked for overlaps 3) there has to be at least one cpu per <vcpusched> From the above checks we can indeed deduce that if we have one <vcpusched> element per CPU we will have at most 'maxvcpus' of them. Drop the explicit check since it's redundant.
-
由 Ján Tomko 提交于
Now that new domains are started inside a QEMU_ASYNC_JOB_START job, we need to pass it down to qemuProcessStartCPUs too. This removes the warning: qemuDomainObjEnterMonitorInternal:1750 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous Introduced by commit 04c721f2, before that this code path was only executed with QEMU_ASYNC_JOB_NONE. (This code is not executed on migration, because qemuMigrationPrepareAny sets the VIR_QEMU_PROCESS_START_PAUSED flag.)
-
由 Peter Krempa 提交于
To simplify further refactors change the way the vcpu count is extracted to use a temp variable rather than juggling with def->maxvcpus.
-
由 Peter Krempa 提交于
To simplify further refactors change the way the vcpu count is extracted to use a temp variable rather than juggling with def.maxvcpus.
-
由 Peter Krempa 提交于
To simplify further refactors change the way the vcpu count is extracted to use a temp variable rather than juggling with def->maxvcpus.
-
由 Peter Krempa 提交于
Use the helper that is necessary to fill out some values rather than allocating it directly.
-
由 Christian Loehle 提交于
Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 23 11月, 2015 4 次提交
-
-
由 Ján Tomko 提交于
We do not have a pointer to the device here, just its source.
-
由 Ján Tomko 提交于
The domain definition is not needed in any of these functions. Only pass it to qemuSetupChardevCgroup, which is used as a callback for virDomainChrDefForeach. Use the right type for passing virDomainObjPtr instead of void* where possible.
-
由 Ján Tomko 提交于
Change CGroup to Cgroup to match other functions in the file.
-
由 Guido Günther 提交于
like I440FX by moving the condition into qemuDomainMachineHasBuiltinIDE and adding more machines. Reference: http://bugs.debian.org/805189
-
- 21 11月, 2015 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1282288 Rather than using just open on the path, allow for the possibility that the path to be opened resides on an NFS root-squash target and was created under a different uid/gid. Without using virFileOpenAs an attempt to get the volume size data may fail if the current user doesn't have permissions to read the volume, such as would be the case if mode wasn't supplied in the volume XML and the default VIR_STORAGE_DEFAULT_VOL_PERM_MODE (e.g. 0600) was used. Under this scenario the owner/group is not root:root, thus this path run under root would fail to open/read the volume. NB: The virFileOpenAs code using OPEN_FORK will only work when the failure is not EACESS/EPERM and the path resolves to a shared file system.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1282288 Although commit id '77346f27' resolves part of the problem regarding creating a qemu-img image in an NFS root-squash environment, it really didn't fix the entire problem. Unfortunately it only masked the problem. It seems qemu-img must open/create the image using 0644, which if used by target.perms would result in the chmod not being called since the mode desired and set match. Although qemu-img could conceivably ignore the mode when creating, libvirt has more knowledge of the environment and can make the adjustment to the mode far more easily by using virFileOpenAs with VIR_FILE_OPEN_FORCE_MODE. If that's successful, then we know on return the file will have the right owner and mode, so we can declare success
-
- 20 11月, 2015 5 次提交
-
-
由 Andrea Bolognani 提交于
Unlike other architectures, ppc64 domains need to lock memory even when VFIO is not used. Change qemuDomainRequiresMlock() to reflect this fact.
-
由 Andrea Bolognani 提交于
The amount of memory a ppc64 domain might need to lock is different than that of a equally-sized x86 domain, so we need to check the domain's architecture and act accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1273480
-
由 Andrea Bolognani 提交于
The function is used everywhere else to check whether the locked memory limit should be set / updated, and it should be used here as well. Moreover, qemuDomainGetMlockLimitBytes() expects the hostdev to have already been added to the domain definition, but we only do that at the end of qemuDomainAttachHostPCIDevice(). Work around the issue by adding the hostdev before adjusting the locked memory limit and removing it immediately afterwards.
-
由 Andrea Bolognani 提交于
This removes a duplication of the logic used to decide whether the memory locking limit should be set.
-
由 Andrea Bolognani 提交于
This can be useful for debugging.
-
- 19 11月, 2015 16 次提交
-
-
由 Jim Fehlig 提交于
Commit 6472e54a unlocks the virDomainObj even if libxlDomainObjEndJob returns false, indicating that its refcnt has dropped to 0. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
Commits b6e19cf4 and 6472e54a missed unref'ing the libxlDriverConfig object. Add missing calls to virObjectUnref. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 John Ferlan 提交于
Commit id '08600de3' changed the prototype to reduce an argument, but didn't adjust the ATTRIBUTE_NONNULL(11) to (10)
-
由 Mikhail Feoktistov 提交于
Diff from v1. 1. Add virCheckFlags() call in vzDomainReboot
-
由 Mikhail Feoktistov 提交于
In virtuozzo we support only en-us keymap for VMs and containers. If keymap is specified than check that it's en-us, otherwise show error message.
-
由 Jiri Denemark 提交于
Remembering to call qemuMonitorSetDomainLog in the right paths before calling qemuProcessStop is annoying and easy to forget. And I already forgot to do so in commit v1.2.8-52-g03890605: logfd may be leaked if QEMU process dies between Prepare and Finish migration phases. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Every caller setting migrateFrom already sets VIR_QEMU_PROCESS_START_PAUSED flag anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessMakeDir is used for creating a per-domain directory in a given parent directory. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart is so big that any nontrivial code should be moved to dedicated functions to make the code easier to read and maintain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Move {Enter,Exit}Monitor calls inside qemuProcessSetLinkStates to simplify qemuProcessStart. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart is so big that any nontrivial code should be moved to dedicated functions to make the code easier to read and maintain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart is so big that any nontrivial code should be moved to dedicated functions to make the code easier to read and maintain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
qemuProcessStart is so big that any nontrivial code should be moved to dedicated functions to make the code easier to read and maintain. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Traditionally, we pass incoming migration URI on QEMU command line, which has some drawbacks. Depending on the URI QEMU may initialize its migration state immediately without giving us a chance to set any additional migration parameters (this applies mainly for fd: URIs). For some URIs the monitor may be completely blocked from the beginning until migration is finished, which means we may be stuck in qmp_capabilities command without being able to send any QMP commands. QEMU solved this by introducing "defer" parameter for -incoming command line option. This will tell QEMU to prepare for an incoming migration while the actual incoming URI is sent using migrate-incoming QMP command. Before calling this command we can normally talk to the monitor and even set any migration parameters which will be honored by the incoming migration. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-