- 18 9月, 2017 16 次提交
-
-
由 John Ferlan 提交于
-
由 Edan David 提交于
Adding functionality to libvirt that will allow querying the interface for the availability of switchdev Offloading NIC capabilities. The switchdev mode was introduced in kernel 4.8, the iproute2-devlink command to retrieve the switchdev NIC feature with command example: devlink dev eswitch show pci/0000:03:00.0 This feature is needed for Openstack so we can do a scheduling decision if the NIC is in Hardware Offload (switchdev) or regular SR-IOV (legacy) mode. And select the appropriate hypervisors with the requested capability see [1]. [1] - https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/enable-sriov-nic-features.htmlReviewed-by: NLaine Stump <laine@laine.org> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1075520 Apart from generic checks, we need to constrain netmask/prefix length a bit. Thing is, with current implementation QEMU needs to be able to 'assign' some IP addresses to the virtual network. For instance, the default gateway is at x.x.x.2, dns is at x.x.x.3, the default DHCP range is x.x.x.15-x.x.x.30. Since we don't expose these settings yet, it's safer to require shorter prefix to have room for the defaults. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: laine@laine.org
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1075520 Currently, all that users can specify for an interface type of 'user' is the common attributes: PCI address, NIC model (and that's basically it). However, some need to configure other address range than the default one. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: laine@laine.org
-
由 Jiri Denemark 提交于
The function checks whether all CPU features used in a CPU definition are specified in cpu_map.xml. https://bugzilla.redhat.com/show_bug.cgi?id=1460086Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Only feature policy is checked on s390, which was previously done in virCPUUpdate, but that's not the correct place for the check once we have virCPUValidateFeatures. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
This new API may be used to check whether all features used in a CPU definition are valid (e.g., libvirt knows their name, their policy is supported, etc.). Leaving this API unimplemented in an arch subdriver means libvirt does not restrict CPU features usable on the associated architectures. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The host CPU definitions reported in the capabilities XML may contain CPU features unknown to QEMU, but the result of virConnectBaselineCPU is supposed to be directly usable as a guest CPU definition and thus it should only contain features QEMU knows about. https://bugzilla.redhat.com/show_bug.cgi?id=1450317Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The filter only needs to know the CPU architecture. Passing virQEMUCapsPtr as opaque is a bit overkill. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
The implementation of virConnectBaselineCPU may be different for each hypervisor. Thus it shouldn't really be implmented in the cpu code. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
They are logged in cpuBaseline anyway. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
For parsing a list of CPU XMLs into a NULL-terminated list of CPU defs. Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1373783Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
- 16 9月, 2017 1 次提交
-
-
由 Cole Robinson 提交于
The macro needs to be defined closer to its usage
-
- 15 9月, 2017 13 次提交
-
-
由 Cole Robinson 提交于
This is required by the fedora packaging guidelines: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines This macro isn't available on stock RHEL6 so provide a backcompat definition https://bugzilla.redhat.com/show_bug.cgi?id=1483293Reported-by: NVille Skyttä <ville.skytta@iki.fi>
-
由 Ville Skyttä 提交于
Owning all created directories is a requirement of the Fedora packaging guidelines https://bugzilla.redhat.com/show_bug.cgi?id=1483293Signed-off-by: NCole Robinson <crobinso@redhat.com>
-
由 John Ferlan 提交于
Luckily it only returns 0 or -1
-
由 John Ferlan 提交于
Commit id 'e02ff020' neglected to use the attrBuf and childBuf in the virDomainDiskSourceFormatNetwork call. So make the necessary alterations to allow usage.
-
由 John Ferlan 提交于
Rather than checking during XML processing, move the check for valid <encryption> into virDomainDiskDefParseValidate and alter the text of the message slightly to be a bit more correct.
-
由 John Ferlan 提交于
Add a test to prove checking for invalid luks disk formatting check. The error message will indicate supplying the <cipher> element is unnecessary.
-
由 John Ferlan 提交于
Rather than checking during XML processing, move the checks for correct and valid auth into virDomainDiskDefParseValidate. This will introduce virDomainDiskSourceDefParseAuthValidate to validate that the authdef stored for the virStorageSource is valid. This can then be expanded to service backingStore sources as well. Alter the message text slightly as well to distinguish between an unknown name and an incorrectly used name. Since type is not a mandatory field, add the NULLSTR() around the output of the unknown error. NB, a config using unknown formatting would fail virschematest since it only accepts 'iscsi' and 'ceph' as "valid" types.
-
由 John Ferlan 提交于
Add a couple of tests to "validate" checks in domain_conf that either a missing secrettype (CONFIG_UNSUPPORTED) or an mismatched secrettype of ceph for an iSCSI disk (INTERNAL_ERROR) will cause a parsing error.
-
由 John Ferlan 提交于
Alter the example to remove the <auth> from: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi-pool' volume='unit:0:0:1' mode='host'/> <auth username='myuser'> <secret type='iscsi' usage='libvirtiscsi'/> </auth> <target dev='vdb' bus='virtio'/> </disk> and <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/> <auth username='myuser'> <secret type='iscsi' usage='libvirtiscsi'/> </auth> <target dev='vdc' bus='virtio'/> </disk> The reality is, it's not even used. For a <source pool> the authdef from the storage source pool will supercede whatever is in the <disk> definition during virStorageTranslateDiskSourcePool processing. In fact, if the pool doesn't have/need authentication, then the authdef would be removed anyway as the storage pool would be handling things. The "proof" for this is in the adjustment to the test to add an <auth> for a disk. The resulting .args file won't add what normally would be added "myname:encodedpassword@" prior to the hostname in the IQN (e.g. iscsi://myname:encodedpassword@iscsi.example.org:3260/...
-
由 Peter Krempa 提交于
Some operations done to rollback disk image labelling and locking might overwrite (or clear) the actual error. Remember the original error when tearing down disk access so that it's not obscured. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1461301
-
由 Peter Krempa 提交于
The helpers allow to simplify restoring original errors in most cases.
-
由 Peter Krempa 提交于
Some cleanup paths overwrite a usefull error message with a less useful one and we then try to preserve the original message. The handlers added in this patch will simplify the operations since they are designed right for the purpose.
-
由 Cole Robinson 提交于
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
-
- 14 9月, 2017 10 次提交
-
-
由 Andrea Bolognani 提交于
Order them more logically and make sure that stuff that doesn't need to be modified frequently if at all, such as the notification settings, are out of the way. Perform other very minor tweaks as well. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Andrea Bolognani 提交于
Since configure automatically picks up as many optional dependencies as possible, installing more packages allows us to improve our test coverage. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
The default distribution is apparently ignored if an explicit test matrix is provided, so we haven't actually been testing the precise plus gcc combo. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Make parts of the build command OS-dependent instead. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
The openwsman header files are at fault here, but precise is entirely unmaintained at this point so the issue will never be fixed. Better to ignore the error and have coverage over the Hyper-V driver than disabling it: if code that would trigger the warning will be added to libvirt, the CentOS CI will catch it. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Andrea Bolognani 提交于
We don't need 50 commits for our purposes, so might as well save some bandwidth and possibly some time by making the clone shallower. Signed-off-by: NAndrea Bolognani <abologna@redhat.com> Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 John Ferlan 提交于
For reference, these were generated by updating a local qemu git repository to the latest upstream, making sure the latest dependencies were met via "dnf builddep qemu" from my sufficiently privileged root account, checking out the v2.10.0 tag, and building in order to generate an "x86_64-softmmu/qemu-system-x86_64" image. Then using a clean libvirt tree updated to master and built, the image was then provided as input: tests/qemucapsprobe /path/to/x86_64-softmmu/qemu-system-x86_64 > \ tests/qemucapabilitiesdata/caps_2.10.0.x86_64.replies With the .replies file in place and the DO_TEST line added and build, then running the following commands: touch tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml VIR_TEST_REGENERATE_OUTPUT=1 ./tests/qemucapabilitiestest to generate tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml and both were added to the commit. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
Interestingly, none of the qemus we have caps for supported it ... Reviewed-by: NEric Blake <eblake@redhat.com>
-
由 Peter Krempa 提交于
Drop all the monitor code necessary to do the downstream block jobs. Reviewed-by: NEric Blake <eblake@redhat.com>
-