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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Init a shared log instance in virtinst/logger.py, and use that
throughout the code base, so we aren't calling directly into
'logging'. This helps protect our logging output from being
cluttered with other library output, as happens with some
'requests' usage
Currently we just call libvirt API which will return all CPU models for
specific architecture known to libvirt and we offer all of them to users
in GUI. Let's switch to domain capabilities where we have more details
about these CPUs such as whether each model is usable with current QEMU
binary. If libvirt can detect the usability we will offer only CPU
models that QEMU can actually run.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Rather than forcing API users to go through the capabilities APIs.
This lets us simplify things in virt-install quite a bit, and is
needed for smarter machine type defaults
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>
This is required in order to ask for correct domcapabilities. If you don't
specify any machine libvirt will return domcapabilities for default machine
which is xenpv.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Instead of hard-coding that ACPI and APIC are enabled by default, detect
their presence from libvirt capabilities and use it.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1215692
(crobinso: Adjust for recently added test case)
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Each guest type can have its own capabilities and we should always ask
only for those capabilities.
The old approach was to get capabilities from libvirt and then for
example cycle trough all guests and return True, if any guest type
supports kvm or pae, etc.
Now we check those capabilities only for the correct guest type
according to defaults and input from user.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
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.
These only work for xen x86, and are less relevant nowadays since HW
virt has been around for a very long time. Also it's tough to be sure
that we aren't giving a bogus warning.
This enables virt-install to create VMs based on ppc64le architecture.
(crobinso: fix minor pylint)
Signed-off-by: Prerna Saxena <prerna@linux.vnet.ibm.com>
After commit 7594cef35f,
pylint show a "access to a protected member" warning.
This patch introduces a static method to solve it.
Signed-off-by: Chen Hanxiao <chenhanxiao@cn.fujitsu.com>
testCPUMap() tries to open /usr/share/libvirt/cpu_map.xml file
and that fails if libvirt is not installed on the system
or cpu_map.xml path is different.
Force it to use tests/capabilities-xml/cpu_map.xml file instead.
Read the list of CPU models trough getCPUModelNames instead of
accessing directly the file cpu_map.xml.
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1060316
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
As for the previous patch, this information is not used anywhere and
this information should be retrieved using the libvirt baselineCPU
API.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
This information is not used anywhere and there is no way to read
it directly from libvirt without parsing the cpu_map.xml file.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
