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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In weird corner cases this can trigger tracebacks, if the boot
page is refreshed while the hardware list changed underneath us.
This is a step in the direction of unwinding it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Historically we have not advertised host-passthrough because it was
not recommended for general usage. That stance is softening,
tools like gnome-boxes already set it as the default, and users
continue to ask about it.
We may change the default in virt-manager but it will take more
discussion. This is a tiny move in the direction of hiding it less
than we already do.
Drop the label for host-model and call it by its libvirt XML name,
since otherwise it's hard to tell which combo choice is for each
value
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This uncovered some areas in details.py we weren't handling that
the search view unselects the current selection
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Share the UI for changing all these disk properties:
- shareable
- readonly
- removable
- cache
- discard
- detect zeroes
Move them all under the 'Advanced options' expander in details, and
add the checkbox options to the addhardware wizard.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Refactor the internals to cleanly separate the pieces that fill in
the UI, and the pieces that react to UI state to dynamically show/hide
fields.
Improve spice GL warnings while he are here, and several other minor
fixes
Signed-off-by: Cole Robinson <crobinso@redhat.com>
RAM is rarely changed from the default
heads does not have any explicit virt-manager support
and both are viewable from the XML editor.
So remove the explicit fields for them
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Privatize a lot of stuff
* Separate out many callbacks as thin wrappers around the real code
* Simplify registering EDIT_ handlers
* Organize things better
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is pretty obscure, and if it's problematic then libvirt
or qemu should be throwing an error or otherwise reporting it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Don't have the caller call a validate function, they all catch
errors anyways. Let the build step raise error if there's a problem
Drop some validation checks that libvirt should be performing for us
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit <15a9502b7b7a263c4d66ff2b3f31c209f58fe0b4> fixed firmware
detection but incorrectly. It will always show only "UEFI" even if
the firmware auto-selection is not used because the function is_uefi()
checks both the old style and the new auto-selection.
We have to check only for the auto-selection option.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
It seems that the index is optional, so use a proper string for this
case.
Fixes commit 00fa6366824669aa6ba65f73fdf8eb115dd2d3b7 in this file.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use whole strings for the labels of disks, including the bus (if
available), and the index.
There are still generic fallbacks for the disk types not explicitly
handled.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Shortcut all the checks, and directly return the whole string (index
included) to show for floppies.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a single string with a placeholder for the path to avoid a string
puzzle.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use placeholders for the bus name, and the index; the latter is part of
the string, to avoid a string puzzle.
Also use vmmAddHardware.disk_pretty_bus() to get the proper translated
string of a bus.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a proper string with placeholders for the controller name and index,
to avoid string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use separate strings for the path case, and for the generic case (i.e.
the version), to avoid string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use a separate string in case it has an associated device to avoid a
string puzzle.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Split the handling of serial, parallel, and console in their own cases,
as the common code is less than the non-common one.
Use separate strings in case the port number is available to avoid
string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Translate the labels for a NIC, both when a MAC address is available and
when it is not.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use separate string in case we have the channel name, and in case we
have the channel type.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
So that the callback doesn't need to be passed into the init function,
and vmmDetails can call that function directly
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Move the opencoded impl out of virt-manager details.py and into
virtinst, since this is entirely about XML comparison. Add tests for
it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
portgroups are a way to group logical chunks of settings inside
a <network> object. They are a quite advanced feature that I expect
many few users are using, and the ones that are using it are certainly
advanced enough to edit the XML directly.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is pretty obscure, and requires a large amount of UI surface
to handle correctly. Users can use the XML editor if they know they
need or want this.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* disk: bus editing: maybe keep this for the customize wizard, but
it should go away for existing disks, changing it for an existing VM is
definitely a 'shoot yourself in the foot' type of thing for most users
"""
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* UI maxmem and maxcpu notions, and related memballoon and cpu hotplug
operations. These have been in the UI forever but I'm not sure people
actually use them. cpu hotplug has always been a mess, and unless the
user plans ahead by setting a high maxmem value ballooning is only good
for reducing memory. These all sound like advanced usage to me that
just confuses the typical usecase of adding more mem or vcpus to an
offline VM. And the hotplug operations with virsh are simple to invoke.
So I'd like to drop this from the UI
"""
The remaining field sets both max and current memory in the
inactive XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* UI maxmem and maxcpu notions, and related memballoon and cpu hotplug
operations. These have been in the UI forever but I'm not sure people
actually use them. cpu hotplug has always been a mess, and unless the
user plans ahead by setting a high maxmem value ballooning is only good
for reducing memory. These all sound like advanced usage to me that
just confuses the typical usecase of adding more mem or vcpus to an
offline VM. And the hotplug operations with virsh are simple to invoke.
So I'd like to drop this from the UI
"""
The remaining UI field now sets both maximum and current VCPU
allocation.
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>
This was proposed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
The default driver_io value we use seems to be sufficient. It's very
rare to hear that users need to change the value to something
different, and if they do, they are advanced enough users that can
edit the XML directly IMO.
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>
