Use a static mapping of translated strings, instead of manipulating the
string.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
A single "Generic" message glued together with capitalized names of bus
and type is a really bad string puzzle:
a) the parts cannot be moved around, while they could depending on the
language
b) the type cannot be translated, and things like mouse/keyboard/tablet
are usually translated
c) "generic" as adjective must get the proper gender depending on the
name it refers to
Hence, unroll 6 more whole strings for the most common combinations of
type and bus. Otherwise, use strings with the type, as it is needed
because of (c) above. At last, fallback to a generic string, still
allowing (a) above. In both cases of fallback, the bus is still properly
translated.
In all the cases, use constants instead of explicit identifier strings.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Translate all the types of controllers (e.g. USB, PCI, etc), so they can
be translated/translitterated in case they need to be.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
The builtin rng backend uses getrandom syscall to generate random, no
external rng source needed, introduced from libvirt v6.1.0.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
Add support for the tpm-spapr device model for pSeries VMs.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
* Add CSS data in config.py and install it
* Strip out all hardcoded colors and use style class annotations
* Fix colors to be more theme appropriate to fix dark theme look
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The way we set controller_model earlier, means all the virtio-scsi
allocation code is essentially never set. That code does still fix
a valid case of when trying to add a scsi device when there isn't
any remaining slots open, but that should be rare enough that I'm
fine telling the user to edit manually set up a controller themselves
first.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
These were removed from the Details dialog previously, but I forgot
to remove them from addhardware too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
There are no more users of interface objects in the code. Remove
all the polling support, and all the remaining references to
interface objects throughout the code base
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* network virtualport configuration: this is some really obscure
stuff for configuring VEPA for macvtap devices. I don't think it gets
any usage in practice. I think a smaller subset of this UI is shared
with openswitch config but I believe it's just a single field, we
could keep that even though I don't think many people use it either
"""
This removes it all. The openvswitch piece was not properly wired
up anyways, since it requires setting virtualport type for a bridge.
For users that know they need that, they can add it via the XML
editor.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We have lots of spapr-* pretty printing and some magic handling
spread around the codebase. These devices have fallen out of favor
and are rarely used, so drop the special handling
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Removing this was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
For a decade, qemu and xen and virt-manager work together to
make setting a manual keymap redundant. Advertising it in the UI does
more harm than good, because users may think they need to specify
one when in the vast majority of cases it will give worse behavior.
With the XML editing UI, users still have a way to do this by hand
if they really know what they are doing.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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
Re-use CharSource, just like libvirt does internally. Adjust all
callers to match. Rename type -> backend_model while we are here,
because type is ambiguous
Move all ./source handling into CharSource, which will be reused by
other device classes as well. This requires us to add ../ handling
into our xmlapi xpath engine
It's not a pattern I think is worth extending in the future, and
make internal refactorings more difficult. Drop it, and drop it
from tpm and char devices since it is now unused
Return the generated virtinst device up through the call chain.
Makes the flow a lot more sensible, and will be needed for separating
device building from extra UI validation/prompting
This doesn't seem to do anything, as we end up with with a
virtio-scsi controller anyway both when using virt-install and
when using the GUI, and it's not correct anyway because there's
nothing preventing ppc64/pseries guests from using virtio-scsi.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Instead of duplicating the code into CLI and GUI move it into graphics
device file which is used from both places. This also fixes a bug in
virt-xml where changing listen to address was not working.
This also changes behavior to always configure one listen type when
using CLI listen option or GUI. If user wants to modify only specific
listen type they can use listens[] options from CLI.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1565968
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Pino Toscano
Cole Robinson
Han Han
Stefan Berger
Fabiano Fidêncio
Andrea Bolognani
Pavel Hrdina
Slavomir Kaslev
Lin Ma