- 13 8月, 2015 2 次提交
-
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1210587 (partial) If a SCSI subsystem <hostdev> element address is provided, we need to make sure the address provided doesn't conflict with an existing or libvirt generated address for a SCSI <disk> element. We can handle this condition in device post processing since we're not generating an address based on some target name - rather it's either generated based on space or provided from the user. If the user provides one that conflicts, then we need to disallow the change. This will fix the issue where the domain XML provided an <address> for the <hostdev>, but not the <disk> element where the address provided ends up being the same address used for the <disk>. A <disk> address is generated using it's assigned <target> 'dev' name prior to the check/validation of the <hostdev> address value.
-
由 Frank Schreuder 提交于
Hot-unplugging a disk from a guest that supports hot-unplugging generates an error in the libvirt log when running QEMU with the "-msg timestamp=on" flag. 2015-08-06 10:48:59.945+0000: 11662: error : qemuMonitorTextDriveDel:2594 : operation failed: deleting drive-virtio-disk4 drive failed: 2015-08-06T10:48:59.945058Z Device 'drive-virtio-disk4' not found This error is caused because the HMP results are getting prefixed with a timestamp. Parsing the output is not reliable with STRPREFIX as the results can be prefixed with a timestamp. Using strstr ensures that parsing the output works whether the results are prefixed or not. Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: NFrank Schreuder <fschreuder@transip.nl>
-
- 12 8月, 2015 10 次提交
-
-
由 Laine Stump 提交于
This reverts commit ede34470, which was apparently written based on testing performed before commits 1e15be1b and 9a12b6 were pushed upstream. Once those two patches are in place, commit ede34470 is redundant, and can even cause incorrect/unexpected behavior when auto-assigning addresses for virtio-net devices.
-
由 Michal Privoznik 提交于
In my previous commit d7f5c889 I tried to introduce support for inbound.floor. But the code change was incomplete. This is the change needed to fully enable the feature. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There's a check right at the beginning of the function that shortcuts if the function was called over all NULL arguments. However, this was meant just as a fool-proof check so that we don't crash if function is used in a bad manner. Anyway, it makes Coverity unhappy as it then thinks any of the arguments could be NULL. Well, with the current state of the code it can't. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
It may happen that an interface don't have any bandwidth set and a new one is to be set. In that case, @ifaceBand will be NULL. This will cause troubles later in the code when deciding what to do. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
Commit 6983d6d2 tried to improve parseRateStr but broke the build instead for compilers that were not able to properly introspect the for loop indexed by the enum resulting into the following error: virsh-domain.c: In function 'parseRateStr': virsh-domain.c:916:13: error: 'field_name' may be used uninitialized in this function [-Werror=maybe-uninitialized] vshError(ctl, _("malformed %s field"), field_name); ^ virsh-domain.c:915:13: error: 'tmp' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (virStrToLong_ullp(token, NULL, 10, tmp) < 0) { ^ Rather than trying to fix the code, refactor the function again by reusing virStringSplit.
-
由 Cole Robinson 提交于
If you pass <disk><serial> XML to UpdateDevice, and the original device didn't have a <serial> block, libvirtd crashes trying to read the original NULL serial string. Use _NULLABLE string comparisons to avoid the crash. A couple other properties needed the change too.
-
由 Laine Stump 提交于
Commit e8d55172 updated the domain post-parse to automatically add pcie-root et al for certain ARM "virt" machinetypes, but didn't update the function qemuDomainSupportsPCI() which is called later on when we are auto-assigning PCI addresses and default settings for the PCI controller <model> and <target> attributes. The result was that PCI addresses weren't assigned, and the controllers didn't have their attribute default values set, leading to an error when the domain was started, e.g.: internal error: autogenerated dmi-to-pci-bridge options not set This patch adds the same check made in the earlier patch to qemuDomainSupportsPCI(), so that PCI address auto-assignment and target/model default values will be set.
-
由 Guido Günther 提交于
When running the test suite using "unshare -n" we might have IPv6 but no configured addresses. Due to AI_ADDRCONFIG getaddrinfo then fails with EAI_NONAME which we should then treat as IPv6 unavailable.
-
由 Laine Stump 提交于
This fixes the crash described here: https://www.redhat.com/archives/libvir-list/2015-August/msg00162.html In short, we were calling ioctl(SIOCETHTOOL) pointing to a too-short object that was a local on the stack, resulting in the memory past the end of the object being overwritten. This was because the struct used by the ETHTOOL_GFEATURES command of SIOCETHTOOL ends with a 0-length array, but we were telling ethtool that it could use 2 elements on the array. The fix is to allocate the necessary memory with VIR_ALLOC_VAR(), including the extra length needed for a 2 element array at the end.
-
由 Andrea Bolognani 提交于
Commit adb865df introduced some changes in ppc64DriverNodeData() that cause libvirtd to crash on startup unless this patch is applied as well.
-
- 11 8月, 2015 28 次提交
-
-
由 Michal Privoznik 提交于
Well, there are just two places that needs adjustment: qemuDomainGetInterfaceParameters - to report the @floor qemuDomainSetInterfaceParameters - now that the function has been fixed, we can allow updating @floor too. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
We have a function parseRateStr() that parses --inbound and --outbound arguments to both attach-interface and domiftune. Now that we have all virTypedParams macros needed for QoS, lets parse even floor attribute. The extended format for the arguments looks like this then: --inbound average[,peak[,burst[,floor]]] Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This macro represents the single missing field we don't expose yet within QoS: inbound.floor. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The function is used to parse a tuple delimited by commas into virNetDevBandwidth structure. So far only three out of fore fields are supported: average, peak and burst. The single missing field is floor. Well, the parsing works, but I think we can do better. Especially when we will need to parse floor too in very close future. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
As sketched in previous commits, imagine the following scenario: virsh # domiftune gentoo vnet0 inbound.average: 100 inbound.peak : 0 inbound.burst : 0 outbound.average: 100 outbound.peak : 0 outbound.burst : 0 virsh # domiftune gentoo vnet0 --inbound 0 virsh # shutdown gentoo Domain gentoo is being shutdown virsh # list --all error: Failed to list domains error: Cannot recv data: Connection reset by peer Program received signal SIGSEGV, Segmentation fault. 0x00007fffe80ea221 in networkUnplugBandwidth (net=0x7fff9400c1a0, iface=0x7fff940ea3e0) at network/bridge_driver.c:4881 4881 net->floor_sum -= ifaceBand->in->floor; This is rather unfortunate. We should not SIGSEGV here. The problem is, that while in the second step the inbound QoS was cleared out, the network part of it was not updated (moreover, we don't report that vnet0 had inbound.floor set). Internal structure therefore still had some fragments left (e.g. class_id). So when qemuProcessStop() started to clean up the environment it got to networkUnplugBandwidth(). Here, class_id is set therefore function assumes that there is an inbound QoS. This actually is a fair assumption to make, there's no need for a special QoS box in network's QoS when there's no QoS to set. Anyway, the problem is not the networkUnplugBandwidth() rather than qemuDomainSetInterfaceParameters() which completely forgot about QoS being disperse (some parts are set directly on interface itself, some on bridge the interface is plugged into). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
So, if a domain vNIC's bandwidth has been successfully set, it's possible that because @floor is set on network's bridge, this part may need updating too. And that's exactly what this function does. While the previous commit introduced a function to check if @floor can be satisfied, this does all the hard work. In general, there may be three, well four possibilities: 1) No change in @floor value (either it remain unset, or its value hasn't changed) 2) The @floor value has changed from a non-zero to a non-zero value 3) New @floor is to be set 4) Old @floor must be cleared out The difference between 2), 3) and 4) is, that while in 2) the QoS tree on the network's bridge already has a special class for the vNIC, in 3) the class must be created from scratch. In 4) it must be removed. Fortunately, we have helpers for all three interesting cases. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
When a domain vNIC's bandwidth is to be changed (at runtime) it is possible that guaranteed minimal bandwidth (@floor) will change too. Well, so far it is, because we still don't have an implementation that allows setting it dynamically, so it's effectively erased on: #virsh domiftune $dom vnet0 --inbound 0 However, that's slightly unfortunate. We do some checks on domain startup to see if @floor can be guaranteed. We ought do the same if QoS is changed at runtime. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
This is no functional change. It's just that later in the series we will need to pass class_id as an integer. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
There is no guarantee that an enum start it mapped onto a value of zero. However, we are guaranteed that enum items are consecutive integers. Moreover, it's a pity to define an enum to avoid using magical constants but then using them anyway. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Martin Kletzander 提交于
Commit a6f9af82 added checking for address colisions between starting and ending addresses of forwarding addresses, but forgot that there might be no addresses set at all. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Andrea Bolognani 提交于
The test cases cover the cpuCompare(), cpuBaseline() and cpuNodeData() implementation.
-
由 Andrea Bolognani 提交于
Now that all the changes have been implemented we can run the test cases once again, after updating them to reflect the new behaviour.
-
由 Andrea Bolognani 提交于
Unlike what happens on x86, on ppc64 you can't mix and match CPU features to obtain the guest CPU you want regardless of the host CPU, so the concept of model fallback doesn't apply. Make sure CPU definitions emitted by the driver, eg. as output of the cpuBaseline() and cpuUpdate() calls, reflect this fact.
-
由 Andrea Bolognani 提交于
All previously recognized CPU models (POWER7_v2.1, POWER7_v2.3, POWER7+_v2.1 and POWER8_v1.0) are internally converted to the corrisponding generation name so that existing guests don't stop working.
-
由 Andrea Bolognani 提交于
This is yet another variation of POWER8. The PVR information comes from arch/powerpc/kernel/cputable.c in the Linux kernel tree.
-
由 Andrea Bolognani 提交于
Instead of relying on a hard-coded mask value, read it from the CPU map XML and use it when looking up models by PVR.
-
由 Andrea Bolognani 提交于
Use multiple PVRs per CPU model to reduce the number of models we need to keep track of. Remove specific CPU models (eg. POWER7+_v2.1): the corresponding generic CPU model (eg. POWER7) should be used instead to ensure the guest can be booted on any compatible host. Get rid of all the entries that did not match any of the CPU models supported by QEMU, like power8 and power8e. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
-
由 Andrea Bolognani 提交于
This will allow us to perform PVR matching more broadly, eg. consider both POWER8 and POWER8E CPUs to be the same even though they have different PVR values.
-
由 Andrea Bolognani 提交于
Use a typedef instead of the plain struct and heap allocation. This will make it easier to extend the ppc64 specific CPU data later on.
-
由 Andrea Bolognani 提交于
The upcoming commits will make heavy modifications to the ppc64 driver, split so that it's easier to review the changes. Instead of updating the test cases so that they pass, possibly only to update them again with the following commit, disable them for the time being. Another commit will update them all in one go once all required changes are in place.
-
由 Andrea Bolognani 提交于
This ensures comparison of two CPU definitions will be consistent regardless of the fact that it is performed using cpuCompare() or cpuGuestData(). The x86 driver uses the same exact code.
-
由 Andrea Bolognani 提交于
Limitations of the POWER architecture mean that you can't run eg. a POWER7 guest on a POWER8 host when using KVM. This applies to all guests, not just those using VIR_CPU_MATCH_STRICT in the CPU definition; in fact, exact and strict CPU matching are basically the same on ppc64. This means, of course, that hosts using different CPUs have to be considered incompatible as well. Change ppc64Compute(), called by cpuGuestData(), to reflect this fact and update test cases accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1250977
-
由 Andrea Bolognani 提交于
ppc64Compute(), called by cpuNodeData(), is used not only to retrieve the driver-specific data associated to a guest CPU definition, but also to check whether said guest CPU is compatible with the host CPU. If the user is not interested in the CPU data, it's perfectly fine to pass a NULL pointer instead of a return location, and the compatibility data returned should not be affected by this. One of the checks, specifically the one on CPU model name, was however only performed if the return location was non-NULL.
-
由 Andrea Bolognani 提交于
A test is considered successful if the obtained result matches the expected result: if that's not the case, whether because a test that was expected to succeed failed or because a test that was supposed to fail succeeded, then something's not right and we want the user to know about this. On the other hand, if a failure that's unrelated to the bits we're testing occurs, then the user should be notified even if the test was expected to fail. Use different values to tell these two situations apart. Fix a test case that was wrongly expected to fail as well.
-
由 Andrea Bolognani 提交于
No functional changes.
-
由 Andrea Bolognani 提交于
The information is not used anywhere in libvirt. No functional changes.
-
由 Andrea Bolognani 提交于
Having the functions grouped together this way will avoid further shuffling around down the line. No functional changes.
-
由 Andrea Bolognani 提交于
-