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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Right now we have:
* memory -> ./currentMemory
* maxmem -> ./memory
* hotplugmaxmem -> ./maxMemory
Which is just a mess to know what we might be really setting behind
the scenes. Rename the properties to match the XML element name, and
adjust all users to the new names. cli options aren't changed though
If USB support is available, we can use USB input devices too.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Unlike other features we have enabled earlier, this one requires
version checks because RISC-V guests have only started using PCI
by default very recently, and we can't have USB without PCI.
More specifically, we need QEMU commit d6c1bd4a2237 (included
in 4.0.0) and libvirt commit 7c48fb08e0cd (included in 5.3.0).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The default machine at the QEMU level is spike_v1.10, but most
people will really want to use the virt machine type instead.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
As long as it's supported by both QEMU and the guest OS,
there's really no reason not to add it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're not including any input devices in the generated XML
for s390x guests, and the results is that it's not possible
to interact with them short of using the serial console or
connecting through ssh, which is fine but probably not what
is expected when graphics are present.
USB input devices are not a good fit for s390x guests: USB
requires PCI, and PCI is not widely available or used on
s390x; VirtIO devices, on the other hand, are a perfect
match since s390x guests use basically no emulated devices
and rely on VirtIO for most functionality.
https://bugzilla.redhat.com/show_bug.cgi?id=1683609
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
libvirt already does this for us, sort of: it will automatically
add a USB keyboard and mouse to ppc64 guests with graphics;
in addition, these devices are impossible to remove.
Unfortunately this results in a pretty poor experience for the
user, since the relative pointing device makes interacting with
the GUI an exercise in frustration.
As of commit 186bb479d0f4, libvirt will still add the USB
keyboard automatically but will skip the USB mouse if a USB
tablet is already present, so by explicitly including USB input
devices in the generated XML we can create guests that are
actually usable.
We can do this unconditionally, without having to worry about
what version of libvirt we're running against: if it's new
enough we'll take advantage of the fix, and if not then the
resulting guest will not be any more broken than it would have
been before.
https://bugzilla.redhat.com/show_bug.cgi?id=1683609
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Right now we're limiting use of virtio-scsi to ppc64/pseries
and aarch64/virt guests, but there's really no reason not to
use it wherever it's available.
This results in virtio-scsi being now used on s390x, where no
other sensible SCSI controller implementation is available
anyway, and x86, where you alreayd didn't want end up using
lsilogic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The code in _add_implied_controllers() tries to add an ibmvscsi
controller if any disk with spapr-vio address type is found;
however, regardless of the specific SCSI controller in use, all
SCSI disks will use the drive address type, so that condition
will never be triggered - which is actually for the best, since
we want to use virtio-scsi on ppc64 anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Add `reorder_boot_order` method to Guest class. It sets the boot order
of the passed `dev` to `boot_index` and adapts all other boot indices
of the guest accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Apart from the fact, that 'virtio' is not a valid scsi controller model
the 'has_virtio_scsi' variable is not needed at all. It is used only
in one condition where both 'has_any_scsi' and 'has_virtio_scsi' has to
be false which can happen only if there is no 'scsi' controller defined
by user.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
A `KeyError` indicates that the `boot_order` input was
invalid. Therefore we shouldn't ignore this error silently.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Don't exclude redirected devices since they're also bootable. They
won't clutter the UI of virt-manager as we're excluding them
explicitly for the UI in the `get_bootable_devices` method defined in
virtManager/domain.py.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move set boot order responsibility to guest XML builder.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add 'get_boot_order' method. This method has an optional parameter for
getting the legacy boot order defined in the OS node of the domain
definition.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move get boot order methods to guest XML builder. For this we must
replace self.get_bootable_devices() with
self.get_bootable_devices(exclude_redirdev=True) in the
_get_device_boot_order and set_device_boot_order to have no
functionality change.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move use_device_boot_order to guest XML builder and rename it into
'set_device_boot_order'.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add a method to the Guest XMLBuilder for getting all bootable devices
of the guest definition with the option to exclude the redirdevs in
the returned list.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Move (find_compare)_device functions to guest.py as it will be used
there in an upcoming patch.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Let's create a new method that defaults to libosinfo's recommended
resources (when they're available) for memory and vcpus.
It'll help us to avoid erroring out whenever virt-install is called
without specifying the memory amount, as the recommended amount of
memory would come from libosinfo.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
VSOCK sockets allow communication between virtual machines and the host they are
running on.
This patch adds vsock device support along with clitest for the new properties.
Signed-off-by: Slavomir Kaslev <kaslevs@vmware.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.
This switch says: if we detect a rhel host, use special version
checks that match rhel backports. This pattern sucks. The way
forward is to have libvirt advertise the bits that are supported,
through domcapabilities. Then virt-manager/virtinst can react
as appropriate.
This is just a big nasty commit.
Turn the OS inspection page into an always available page that
shows the libosinfo name from the domain metadata XML. Use oslist.py
and have it absorb more of the common behavior needed by create.py
and details.py. Add UI tests for it all
Don't rely on libvirt's default. This makes any XML changes more
explicit, and can help other parts of the code that may depend on
a machine type being encoded
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
This changes all the callers to invoke start_install directly on the
Installer object. We still stash the installer instance inside the
guest object in create.py, just for simplicity
Really it makes more conceptual sense that the Installer class
should handle start_install and friends, but that's difficult
because the layering is all mixed up.
Start to untangle it by moving all those routines to the Installer
class and adding wrapper APIs to Guest to maintain compat for now.
Separate the install from postinstall config case more clearly,
so the installer is only ever altering bits for the install-time
case, and Guest handles actually writing postinstall bits
And move all the Guest logic there.
We need to add an xmlbuilder helper _prop_is_unset to be able to
determine if a bool property is unset, in our quest to remove
default_* xmlbuilder bits
We shouldn't concern ourselves with whether the OS supports qemu_ga
out of the box, just set up the channel regardless, as long as
virtio-serial is supported.
This adds the channel for some aarch64 cases which didn't have OS
specified, but that's desired IMO
- Remove anything for less than qemu 0.12 or libvirt 0.10, basically
rhel6 vintage stuff
- Open code some simple checks
- Remove some that are only used for unnecessary error reporting
This case will still work, but be a bit slower, which is fine. Nowadays
-M virt is much better for virt usage and nearly everyone is using that,
so save us the complication. This was really only useful when
bootstrapping arm virt support
Let libvirt/libxl fill it in. This was required for rhel5 xen at
least, but we don't support that anymore and modern libvirt seems
to do the right thing and fill it in for us.
This type of validation should really be done at the libvirt level,
particularly for a non-mandatory feature like cpuset. Otherwise
it's just more code for us to test which will rarely be hit by users
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>
Lookup the domain capabilities CPU model and compare with
the host capabilities CPU model and if they are not equal
set the guest's CPU model to None.
(crobinso: compare against 'custom' list not 'host-model', move
to separate function)
The way we enumerate devices doesn't conform with the way all
other XMLBuilder instances expose child objects. Move more towards
that direction.
This requires some virt-xml and cli.py hacks but we will remove those
in future patches
Moves the libxml2 bits to a separate xmlapi file and class, a bunch
of cleanups to xmlbuilder internals dealing with XML stuff.
The main point is to experiment with different XML library impls,
since libxml2 is unfun to deal with and we are having python3
issues like
https://bugzilla.gnome.org/show_bug.cgi?id=776815
Currently the domain CPU class has a child property like:
siblings = XMLChildProperty(_CPUCellSibling)
If a user wants to add a new sibling, we add a convenience function:
def add_sibling(self):
obj = _CPUCellSibling(self.conn)
self.add_child(obj)
return obj
Rather than require every child property to define a similar matching
helper function, this adds infrastructure in xmlbuilder to do this
generically for every child property. Now callers can do
obj = guest.cpu.siblings.add_new()
In Python 2 the raise command can take 3 objects as arguments which
are used to specify the exception to be raise as well as detailed
information and traceback [1].
In Python 3 the sintax is changed and now the keyword "from" and
"with_traceback" keyworkds are used to specify this information. [2]
Example which has the same behaviour for both Python 2 and 3:
try:
a = 1/0
except Exception:
import sys
err = sys.exc_info()
try:
raise Exception("Test")
except:
pass
if sys.version_info[0] == 2:
exec("raise err[0], err[1], err[2]")
else:
raise
Add vcpupin support to virt-install so that it can create guest
domains with statically allocated vcpu pinning towards a given cpuset.
Syntax: to pin vcpu=0 to cpuset="1,3" and vcpu=1 to cpuset=2
--cputune vcpupin0.vcpu=0,vcpupin0.cpuset=1,3,vcpupin1.vcpu=1,vcpupin1.cpuset=2
generates below XML description for the guest domain.
<cputune>
<vcpupin vcpu="0" cpuset="1,3"/>
<vcpupin vcpu="1" cpuset="2"/>
</cputune>
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
Fix all E125:
Continuation line with same indent as next logical line
Also remove ignore options of E125
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
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>
This element controls hot(un)plugable memory for the guest in
addition to the initial memory configured by <memory> element.
One has to configure <maxMemory> and guest numa nodes using <numa>
element to enable hot(un)plug of memory modules.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When an error occurs when the VM creation wizard tries to start the VM,
it's then not possible to press again the "Finish" button to try again
to start it, as this errors out with:
Traceback (most recent call last):
File "/home/teuf/redhat/virt/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/home/teuf/redhat/virt/virt-manager/virtManager/create.py", line 2341, in _do_async_install
guest.start_install(meter=meter)
File "/home/teuf/redhat/virt/virt-manager/virtinst/guest.py", line 457, in start_install
raise RuntimeError(_("Domain has already been started!"))
RuntimeError: Domain has already been started!
This is caused by code introduced in commit fc6778 which does not reset
self.domain to None when an exception is caught.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This is for xml like:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
...
</devices>
<qemu:commandline>
<qemu:arg value='-newarg'/>
<qemu:env name='QEMU_ENV' value='VAL'/>
</qemu:commandline>
</domain>
Requires some extensions to the xmlbuilder infrastructure
Since we only attempt to add a default USB controller for x86, match
it by only trying to add redir devices on x86 as well. Fixes a uitests
failure for ppc testing, since the test:/// driver doesn't add an
implied USB controller, and libvirt now validates that one was provided.
