IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
RISC-V doesn't support KVM yet, so we are forced to use TCG
on x86 until that's working.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
There's been various discussions about changing the x86 default
from 'pc' to 'q35' over the years, but it's unlikely to happen
at the qemu or libvirt level for compatibility reasons. So
let's start using it for new enough OS that support it.
The copyright headers in every file were chjanged in this previous commit
commit b6dcee8eb7
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 20 15:00:02 2018 -0400
Use consistent and minimal license header for every file
Where before this they said "
"either version 2 of the License, or (at your option) any later version."
Now they just say
"GNU GPLv2"
This fixes it to say "GNU GPLv2 or later" again.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If we try to run the testsuite on anything older than libvirt 3.1,
it immediately throws an exception before processing any tests,
due to choking on parsing drm bits from testdriver.xml. This global
failure is only due to sloppy coding though.
Turn all test cases that use testdriver.xml into skips in this case,
so we can at least get some test coverage otherwise.
Right now, most test cases will create a libvirt test driver using
tests/testdriver.xml. This is problematic for 2 reasons:
1) testdriver.xml is 3500 lines of XML, and it's parsed hundreds of
times. Opening it is responsible for about 25% of test suite time
2) Older libvirt chokes on testdriver.xml, meaning the test suite will
be useless there. This is a recurring problem as new features are
added to testdriver.xml
Most test cases don't actually need all the test state in testdriver.xml
though. So this creates a smaller testsuite.xml which has a lower
libvirt requirement and is much quicker to parse. New XML bits should
continue to go into testdriver.xml so we can keep testsuite.xml as
the more stripped down option.
In Python 2 comparison between int and None is allowed but in
Pyhton 3 it is not.
Example:
Pyhton 2
>>> None > 0
False
Python 3
>>> None > 0
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'NoneType' and 'int'
Have the internal polling functions not touch the connection cache.
This let's us not worry about the connection cache in the test suite,
where clear_cache wasn't 100% correct.
If we detect that the UEFI image is build to require SMM feature we
should configure the guest to enable SMM feature and set q35 machine
type. Without this user wouldn't be able to boot the guest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1387479
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Similar to what we do with libvirt. Was never really relevant before,
but some of the namespace XML stuff can be a bit noisy even though it
doesn't have any functional impact that I can tell
Add a capatilities xml file for s390x ,the capatility for IBM
Distro called KVMIBM,mainly focus on a KVM hypervious on S390x.
Also add a clitest by using virt-install.
For architecture "s390x",the disk and the network device are base
on "virtio" bus.The cdrom is based on "scsi".So set the default
cdrom bus as "scsi",the default bus as "virtio".Also the default
machine type is set to "s390-ccw-virtio" as it is the only supported
in "s390x".Also add a test cast of virt-install by cdrom in s390x.
(crobinso: Tweak test suite and minor formatting stuff)
Make it clear which ones are used for the caps unit tests, and which
are for cli/UI testing and can be updated at will. And drop a bunch
of outdated stuff.
Try to use --boot uefi if the user hasn't already specified loader params,
or a kernel to boot. If we can't determine a UEFI setup, just print a
warning.
