- 24 8月, 2015 3 次提交
-
-
由 Martin Kletzander 提交于
The output of that function was not tested until now. In order to keep the paths in /tmp, the test driver config is "fixed" as well. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
We are automatically generating some socket paths for domains, but all those paths end up in a directory that's the same for multiple domains. The problem is that multiple domains can each run with different seclabels (users, selinux contexts, etc.). The idea here is to create a per-domain directory labelled in a way that each domain can access its own unix sockets. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1146886Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Erik Skultety 提交于
JSON data that are used to initialize tests in virnetdaemontest should be in a consistent format, i.e. not using tabs for indentation, those should be replaced by spaces.
-
- 22 8月, 2015 1 次提交
-
-
由 Andrea Bolognani 提交于
-
- 13 8月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
The numad hint stored in priv->autoNodeset is information that gets lost during daemon restart. And because we would like to use that information in the future, we also need to save it in the status XML. For the sake of tests, we need to initialize nnumaCell_max to some value, so that the restoration doesn't fail in our test suite. There is no need to fill in the actual numa cell data since the recalculating function virCapabilitiesGetCpusForNodemask() will not fail, it will just skip filling the data in the bitmap which we don't use in tests anyway. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 11 8月, 2015 8 次提交
-
-
由 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 提交于
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 提交于
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 提交于
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.
-
由 Laine Stump 提交于
This patch modifies virSocketAddrGetRange() to function properly when the containing network/prefix of the address range isn't known, for example in the case of the NAT range of a virtual network (since it is a range of addresses on the *host*, not within the network itself). We then take advantage of this new functionality to validate the NAT range of a virtual network. Extra test cases are also added to verify that virSocketAddrGetRange() works properly in both positive and negative cases when the network pointer is NULL. This is the *real* fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653 Commits 1e334a and 48e8b9 had earlier been pushed as fixes for that bug, but I had neglected to read the report carefully, so instead of fixing validation for the NAT range, I had fixed validation for the DHCP range. sigh.
-
- 10 8月, 2015 15 次提交
-
-
由 Martin Kletzander 提交于
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1150484Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
This will be used with a virtio-scsi controller later on. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Martin Kletzander 提交于
Since its introduction in 2011 (particularly in commit f4324e32), the option doesn't work. It just effectively disables all incoming connections. That's because the client private data that contain the 'keepalive_supported' boolean, are initialized to zeroes so the bool is false and the only other place where the bool is used is when checking whether the client supports keepalive. Thus, according to the server, no client supports keepalive. Removing this instead of fixing it is better because a) apparently nobody ever tried it since 2011 (4 years without one month) and b) we cannot know whether the client supports keepalive until we get a ping or pong keepalive packet. And that won't happen until after we dispatched the ConnectOpen call. Another two reasons would be c) the keepalive_required was tracked on the server level, but keepalive_supported was in private data of the client as well as the check that was made in the remote layer, thus making all other instances of virNetServer miss this feature unless they all implemented it for themselves and d) we can always add it back in case there is a request and a use-case for it. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
This is backed by the qemu device xio3130-downstream. It can only be connected to a pcie-switch-upstream-port (x3130-upstream) on the upstream side.
-
由 Laine Stump 提交于
This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
The downstream ports of an x3130-upstream switch can each have one of these plugged into them (and that is the only place they can be connected). Each xio3130-downstream provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. Apparently an entire set of x3130-upstream + several xio3130-downstreams can be hotplugged as a unit, but it's not clear to me yet how that would be done, since qemu only allows attaching a single device at a time. This device will be used to implement the "pcie-switch-downstream-port" model of pci controller.
-
由 Laine Stump 提交于
this is backed by the qemu device x3130-upstream. It can only plug into a pcie-root-port or pcie-switch-downstream-port.
-
由 Laine Stump 提交于
This controller can be connected only to a pcie-root-port or a pcie-switch-downstream-port (which will be added in a later patch), which is the reason for the new connect type VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides 32 ports (slot=0 to slot=31) on the downstream side, which can only have pci controllers of model "pcie-switch-downstream-port" plugged into them, which is the reason for the other new connect type VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
-
由 Laine Stump 提交于
This is the upstream part of a PCIe switch. It connects to a PCIe port (but not PCI) on the upstream side, and can have up to 31 xio3130-downstream controllers (but no other types of devices) connected to its downstream side. This device will be used to implement the "pcie-switch-upstream-port" model of pci controller.
-
由 Laine Stump 提交于
This is backed by the qemu device ioh3420. chassis and port from the <target> subelement are used to store/set the respective qemu device options for the ioh3420. Currently, chassis is set to be the index of the controller, and port is set to "(slot << 3) + function" (per suggestion from Alex Williamson).
-
由 Laine Stump 提交于
This controller can be connected (at domain startup time only - not hotpluggable) only to a port on the pcie root complex ("pcie-root" in libvirt config), hence the new connect type VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that will accept any PCI or PCIe device. New attributes must be added to the controller <target> subelement for this - chassis and port are guest-visible option values that will be set by libvirt with values derived from the controller's index and pci address information.
-
由 Laine Stump 提交于
This is a PCIE "root port". It connects only to a port of the integrated pcie.0 bus of a Q35 machine (can't be hotplugged), and provides a single PCIe port that can have PCI or PCIe devices hotplugged into it. This device will be used to implement the "pcie-root-port" model of pci controller.
-
由 Laine Stump 提交于
This uses the new subelement/attribute in two ways: 1) If a "pci-bridge" pci controller has no chassisNr attribute, it will automatically be set to the controller's index as soon as the controller's PCI address is known (during qemuDomainAssignPCIAddresses()). 2) when creating the commandline for a pci-bridge device, chassisNr will be used to set qemu's chassis_nr option (rather than the previous practice of hard-coding it to the controller's index).
-
由 Laine Stump 提交于
There are some configuration options to some types of pci controllers that are currently automatically derived from other parts of the controller's configuration. For example, in qemu a pci-bridge controller has an option that is called "chassis_nr"; up until now libvirt has always set chassis_nr to the index of the pci-bridge. So this: <controller type='pci' model='pci-bridge' index='2'/> will always result in: -device pci-bridge,chassis_nr=2,... on the qemu commandline. In the future we may decide there is a better way to derive that option, but even in that case we will need for existing domains to retain the same chassis_nr they were using in the past - that is something that is visible to the guest so it is part of the guest ABI and changing it would lead to problems for migrating guests (or just guests with very picky OSes). The <target> subelement has been added as a place to put the new "chassisNr" attribute that will be filled in by libvirt when it auto-generates the chassisNr; it will be saved in the config, then reused any time the domain is started: <controller type='pci' model='pci-bridge' index='2'> <model type='pci-bridge'/> <target chassisNr='2'/> </controller> The one oddity of all this is that if the controller configuration is changed (for example to change the index or the pci address where the controller is plugged in), the items in <target> will *not* be re-generated, which might lead to conflict. I can't really see any way around this, but fortunately if there is a material conflict qemu will let us know and we will pass that on to the user.
-
由 Laine Stump 提交于
This new subelement is used in PCI controllers: the toplevel *attribute* "model" of a controller denotes what kind of PCI controller is being described, e.g. a "dmi-to-pci-bridge", "pci-bridge", or "pci-root". But in the future there will be different implementations of some of those types of PCI controllers, which behave similarly from libvirt's point of view (and so should have the same model), but use a different device in qemu (and present themselves as a different piece of hardware in the guest). In an ideal world we (i.e. "I") would have thought of that back when the pci controllers were added, and used some sort of type/class/model notation (where class was used in the way we are now using model, and model was used for the actual manufacturer's model number of a particular family of PCI controller), but that opportunity is long past, so as an alternative, this patch allows selecting a particular implementation of a pci controller with the "name" attribute of the <model> subelement, e.g.: <controller type='pci' model='dmi-to-pci-bridge' index='1'> <model name='i82801b11-bridge'/> </controller> In this case, "dmi-to-pci-bridge" is the kind of controller (one that has a single PCIe port upstream, and 32 standard PCI ports downstream, which are not hotpluggable), and the qemu device to be used to implement this kind of controller is named "i82801b11-bridge". Implementing the above now will allow us in the future to add a new kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge device, but instead uses something else (which doesn't yet exist, but qemu people have been discussing it), all without breaking existing configs. (note that for the existing "pci-bridge" type of PCI controller, both the model attribute and <model> name are 'pci-bridge'. This is just a coincidence, since it turns out that in this case the device name in qemu really is a generic 'pci-bridge' rather than being the name of some real-world chip)
-
- 09 8月, 2015 1 次提交
-
-
由 Laine Stump 提交于
If a pci address had a function number out of range, the error message would be: Insufficient specification for PCI address which is logged by virDevicePCIAddressParseXML() after virDevicePCIAddressIsValid returns a failure. This patch enhances virDevicePCIAddressIsValid() to optionally report the error itself (since it is the place that decides which part of the address is "invalid"), and uses that feature when calling from virDevicePCIAddressParseXML(), so that the error will be more useful, e.g.: Invalid PCI address function=0x8, must be <= 7 Previously, virDevicePCIAddressIsValid didn't check for the theoretical limits of domain or bus, only for slot or function. While adding log messages, we also correct that ommission. (The RNG for PCI addresses already enforces this limit, which by the way means that we can't add any negative tests for this - as far as I know our domainschematest has no provisions for passing XML that is supposed to fail). Note that virDevicePCIAddressIsValid() can only check against the absolute maximum attribute values for *any* possible PCI controller, not for the actual maximums of the specific controller that this device is attaching to; fortunately there is later more specific validation for guest-side PCI addresses when building the set of assigned PCI addresses. For host-side PCI addresses (e.g. for <hostdev> and for network device pools), we rely on the error that will be logged when it is found that the device doesn't actually exist. This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004596
-
- 04 8月, 2015 2 次提交
-
-
由 Daniel P. Berrange 提交于
In gnutls 3.4.3 there is a regression in the loading of private keys via gnutls_x509_privkey_import. We already have a workaround to deal with failures on older gnutls, but the error code that the new gnutls returns is different. Extend the workaround so that is checks for GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE too. See also gnutls https://bugzilla.redhat.com/show_bug.cgi?id=1250020Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Kothapally Madhu Pavan 提交于
PowerPC pseries based VMs do not support a floppy disk controller. This prohibits libvirt from creating qemu command with floppy device. Signed-off-by: NKothapally Madhu Pavan <kmp@linux.vnet.ibm.com> https://bugzilla.redhat.com/show_bug.cgi?id=1180486Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 03 8月, 2015 4 次提交
-
-
由 Andrea Bolognani 提交于
This makes sure the subcore-unaware CPU counting logic is used whenever the configuration is invalid.
-
由 Andrea Bolognani 提交于
This makes sure CPUs are counted correctly when some of the cores are completely offline.
-
由 Andrea Bolognani 提交于
This makes sure CPUs are counted correctly when using the default configuration, that is, all primary threads are online and all secondary threads are offline.
-
由 Shivaprasad G Bhat 提交于
The nodeGetThreadsPerSubcore() function is mocked to return 8 for ppc64 tests, which corresponds to the default subcore mode. Update the expected output for the deconfigured-cpus nodeinfo test to account for this change. Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com> Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
-
- 27 7月, 2015 2 次提交
-
-
由 Martin Kletzander 提交于
Commit 2094d01e forgot to rename two more files. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Daniel Veillard 提交于
Simplest was just to rename that extra long name and move files in git accordingly
-
- 24 7月, 2015 3 次提交
-
-
由 Chris J Arges 提交于
Add a testcase for the previous change to ensure zero capacity volumes can be defined without a backing store. Signed-off-by: NChris J Arges <chris.j.arges@canonical.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>
-
由 Luyao Huang 提交于
As there is a regression in use vcpupin get info, introduce a new function to test the virsh client. Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-