There is not really anything to leave out of the string, simply
translate it as a whole.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Use plural forms for strings that depend on a runtime value, like a
count. This way they will get the proper string for the actual value.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Turn the menu labels into GTK accelerator strings, so we can parse them
to convert them into a proper user representation.
There is a small behaviour change: the menu items do not have mnemonics
anymore by default.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
It seems that the index is optional, so use a proper string for this
case.
Fixes commit 00fa636682 in this file.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
There is no point to translate an internal regular expression; worse,
a wrong translation can break the regular expression.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Create single strings for connection/uri hints & tooltips, so it is
easier to translate them, and there are not glued like puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Create single strings for the networks in the clone dialog, including
all the available information at once instead of join pieces together.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Do not split the error messages and the error details, but rather use a
single string with proper placeholders. This avoids string puzzles.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Create the complete sentence as single message, instead of joining an
existing message with few words more.
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 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>
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>
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 as a whole the UI description of a URI along with the detail
for it, if available. This way there is no string puzzle, and it is
possible to tune the detail string according to the language.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Translate the whole string of a title in the migration dialog, including
the markup, so there is no string puzzle.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
When updating the checkbox aobut the automatic port, set a full string
(without or with the port) instead of "cutting" an existing label.
Not only it avoids to manipulate a UI string, it also allows translators
to properly translate the whole string that includes a port.
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>
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>
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>
There's valid cases where a VM can be defined with a conflicting MAC
address. Prior to ebd6091cc8 and related refactorings we were more
lax here if the conflicting VM wasn't running, but now we are blocking
some valid usage.
Hoist the validation check up to cli.py and add --check mac_in_use=off
to skip the validation. Advertise it like we do for other checks, so
now a collision error will look something like:
The MAC address '22:11:11:11:11:11' is in use by another virtual
machine. (Use --check mac_in_use=off or --check all=off to override)
Reported-by: Pino Toscano <ptoscano@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit v2.2.1-200-g4c3c53f7 ("virtManager: Remove network portgroup
UI") removed 'portgroup', the fourth value of the returned tuple in
get_network_selection(), and all related code that was using this
extra value.
That change forgot to change the line where, if no rows are found, a
tuple with "None" values is returned. The "None" tuple is still
returning 4 "None" values. Since no remaining code is checking for
a fourth value, this is benign and has no impact in the logic.
'pylint' does not seem to care though, and it is complaining about
'unbalanced-tuple-unpacking' because, in the condition mentioned above,
a fourth "None" value is returned and no one is bothering checking for
it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.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>
Rather than build a guest and installer instance depending on where
we are in the UI, track each input property in an explicit class, so
we can rebuild the guest/installer on demand with data accumulated
up to that point.
This makes the flow easier to follow and simplifies a lot of hacks we
have to do when backing up through the wizard, because we are trying
to unwind changes from an existing object, rather than just blowing
it away and easily reassembling it with updated info.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Replace the is_session and is_system distinction with variants
of is_privileged. This matches what libvirt uses internally, and
will help with supporting qemu:///embed at some point
Signed-off-by: Cole Robinson <crobinso@redhat.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>
* Simplify the queue data, just push in VM data to refresh
* Do less work in threads
* Slight rework of updating inspection data in the VM
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit 419f8cd31b messed up the dopoll rework, which meant we
never called stats polling on the master object list. Fix it, but
do so by unwinding the redundant internal _update routines
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Generally this doesn't work with qemu metadata locking nowadays,
and it was never a safe idea to begin with, because disk contents
could be in an inconsistent state.
https://bugzilla.redhat.com/show_bug.cgi?id=1725330
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>
Taken from virt-manager code. Move it here because it is strictly
an XML operation, and it will be easier to unit test
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Comment the individual classes
* Move abstract methods to their own logical section
* Simplify some shared code calls
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Pull the remove_devobj_internal call outside of the async job,
otherwise we can have X11 threading issues
Signed-off-by: Cole Robinson <crobinso@redhat.com>
remove_devobj_internal function handles more things than vm.remove_device.
We should call it first before performing the storage deletion.
Reviewed-by: Cole Robinson <crobinso@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>
This layout is closer to what most python modules have nowadays.
It also simplifies testing and static analysis setup.
Keep virt-* wrappers locally, for ease of running these commands
from a git checkout.
Adjust the wrapper binaries we install on via packaging to be
pure python, which makes things like running gdb easier.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Otherwise when we press enter for an already selected OS, it chooses
the first alphabetic entry in the list, overwriting our selection
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Since the page requires input and can't progress until the user enters
some value here, grab focus for the OS list
Signed-off-by: Cole Robinson <crobinso@redhat.com>
For the dialog flow, these options are the same, the only effect
is that there's no longer an initial network boot phase.
PXE is dependent on an external server setup that is not common
in the scheme of things, so giving it a first class option on the
front of the new VM wizard isn't really sensible. Users that want
to PXE boot can easily do so via the 'customize before install'
option, or just manually create a VM and edit the boot device as
they see fit.
Explicitly advertising a Manual option is nicer for users that
just want to create a VM and deal with install later, among many
other minor use cases.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add an info message that these can be set via the
'Customize before install' option. Duplicating this doesn't add a ton
of value here IMO
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>
And drop the explicit forward device listing. Similar to what
we did with bridge/macvtap domain <interface>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Some related bits were discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
macvtap is problematic for inexperienced users so we shouldn't
be broadly advertising it, plus our device listing was incomplete
anyways.
Both bridge and macvtap device listing are largely dependent on
the libvirt virInterface APIs, which have varying degrees of
completeness across distros and are not particularly reliable to
begin with.
Drop both of these in favor of the available support for manually
specifying a device name
Signed-off-by: Cole Robinson <crobinso@redhat.com>
virt-manager's logic is hard to follow, and gives weird results
by just choosing the first bridge device it finds more or less.
Use virt-install's logic: bridge if it is the default route,
otherwise network 'default' if it exists
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Similar to the bridge option. We will be removing the explicit
device listing support soon, so this will be required for specifying
a macvtap device
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Some related bits were discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
"""
* macvtap is kinda problematic in general because it doesn't provide
out of the box host<->guest communication, and it requires a
special XML option just to get working ipv6. Users that know they
want it usually know this distinction, but if someone chooses it
without understanding the implications it can cause confusion.
This puts it hovering the intermediate/advanced user line which
makes me want to not advertise it as prominently as we currently do,
with an explicit list of host interfaces
"""
Part of this is that the only source_mode that will work in a useful
way for the vast majority of users is mode=bridge. Any of the other
modes either require special hardware, permissions, or other
configuration. Default to bridge mode. The XML editor is there for
anyone that knows they need something different
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 should be a no-op.
* Remove unused is_active field
* Access row indexes with named fields
* Move the row building outside the main class, to make it clear
these are just helper methods
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>
Errors from libvirt can be super long, and stretch out the dialog like
crazy.
This causes some changes in test suite output, so adjust tests to
match
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>
This is another advanced feature with a limited appeal. Users that
know they need this can set it directly with the XML editor
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a very advanced field that is only shown for a quite
advanced disk device='lun' config. Users that know they need this
can easily set the value 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
"""
* disk: storage format: this was from before the days when we
storage-ified everything and we could get the disk format wrong, telling
qemu it has a raw image when it's qcow2. shouldn't be needed anymore for
normal virt usage
"""
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: serial: I know this is useful in some cases but seems quite
obscure. I think the XML editor is fine unless there's some common
usecase I'm missing
"""
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was discussed here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
tlsPort is an advanced config feature. With the XML editing support,
it's less important to have this as a first class UI element. Users
that know they need this setting can set it directly in the XML
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>
* Explicitly define the build 'cb', don't use lambda
* Rename pollhelpers arguments, clarifying use of cb
* Check support status in pollhelpers
* Move 'dopoll' checking up a level in vmmConnection
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will be more important when we drop old domain polling APIs,
because it will be more likely we encounter an old libvirt or weird
connection without the expected API support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We should try to hide all the self.vm vs self.disk differences into
individual functions to make the code easier to follow and to avoid
touch those values by accident in the future
Reviewed-by: Cole Robinson <crobinso@redhat.com>
For a shutoff VM, If user select uefi firmware auto selection, e.g.
<os firmware='efi'>
...
</os>
Its firmware information is set to 'BIOS' in details, This is incorrect.
This fixes it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Lin Ma <lma@suse.com>
Wire up stoppping of the time setting thread for actions that make
setting of guest time pointless.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
With the potential for annoyance eliminated, raise the timeout for guest
agent connectivity to 30 seconds.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Make the guest agent wait timeout and sleep interval properties of the
thread manager class better visibility and easier adjustment.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Sleeping in a loop waiting for the qemu guest agent to come online would
leave an annoying progress dialog while the domain would actually be
fully useable already. Additionally, multiple progress dialogs could
actually accumulate on screen if the user managed to suspend/resume fast
enough or the timeout was just long enough.
Defer regular retries into a separate thread to allow the progress
dialog to disappear immediately after the actual action completed. The
thread is encapsulated in a new class _vmmDomainSetTimeThread which
holds state, decides whether to at all wait for an agent to come online
or even try to set the guest time in the first place. It also holds
state (thread running or not), configuration (timeout and retry
interval) and provides an interface to start and stop the time setting
operation.
A later patch will wire up stopping the operation.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Sleeping in a loop waiting for the qemu guest agent to come online
leaves an annoying progress dialog while the domain may actually be
fully useable already. Additionally, multiple progress dialogs can
actually accumulate on screen if the user manages to suspend/resume fast
enough or the timeout is just long enough.
To avoid these, we want to defer retries into a separate thread to allow
the progress dialog to disappear immediately after the actual action
completed.
In preparation for that, add a new class _vmmDomainSetTimeThread that
will eventually manage that separate thread for guest time setting
operations. Move the current code for waiting for the qemu guest agent
into it without any semantic changes.
Make set_time() and agent_read() of vmmDomain accessible from the
outside so that _vmmDomainSetTimeThread can call back into them. Add
has_agent() to be able to find out if the domain has an agent configured
without leaking the actual agent config.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Just return the boolean value of the condition for simlicity.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Do not join two parts of sentences together, because it is problematic
to translate. Instead, use a different sentence depending on the
condition.
Fixes commit d52c9d1ffa.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Add a confirmation dialog when creating a new snapshot if there is saved
memory state so the user is aware that memory state will not be part of
the snapshot.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Refuse to restore a non-running state from snapshot while there is saved
memory state in order to avoid filesystem corruption. Present a message
to the user to that effect and let them choose to either abort the
operation or drop the saved state before restoring the snapshot.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
snap.is_running() returns a boolean and checking that against
VIR_DOMAIN_RUNNING worked by pure coincidence only. Just use the bool
value and give it a more speaking name while at it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
we should let users decide whether they want to also delete the
storage files or just dev from UI when they click the Remove button
Reviewed-by: Cole Robinson <crobinso@redhat.com>
LXC can be many things and in particular when seeing just "LXC" in the
virt-manager UI one might think of either
- Libvirt-LXC => https://libvirt.org/drvlxc.html
- Linuxcontainers LXC => https://linuxcontainers.org
Clarify that this is specifically Libvirt-LXC
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Wire up setting of guest time on snapshot restore and resume from pause.
Do not try to set time if the restored snapshot does not contain a
running domain state.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
For qemu, only run the API if the VM has the qemu guest agent in the
XML. If it is present, wait for it to come online instead of
unconditionally retrying a number of times.
Reuse agent function agent_ready() from refresh_interface_addresses()
and refactor it into two methods of which get_agent() can be used to
check for agent presence and further work with the channel object.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Only run the API for qemu and test drivers, they are the only ones
that support it. This will save spamming logs with error output.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Suggested-by: Cole Robinson <crobinso@redhat.com>
Use a potentially available agent inside the domain to update guest time
after resume. Based on the same function in Nova[1].
[1] 414df1e56e
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
https: //bugzilla.redhat.com/show_bug.cgi?id=1222069
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
This ensures the Guest object domcaps cache is primed as well, which
prevents the CPU security features handling from constantly refetching
domcaps info.
We need to tweak the cache invalidation check in Guest to handle
some of the test suite hackery we do
Signed-off-by: Cole Robinson <crobinso@redhat.com>
During startup virtinst.StoragePool.build_default_pool() tries to
determine whether the default storage pool already exists. Because
events have not yet been processed, the list of existing storage pools
is still empty. Therefore it seems as if it does not exist yet and
build_default_pool() falls back to creating it which causes an error
message from libvirtd in the system log:
libvirtd: operation failed: pool 'default' already exists with uuid.
Move default pool creation after event processing to avoid these
redundant creation attempts.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
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
qemu nowadays should reject the common cases here with its default
image locking. Our impl wasn't very good anyways so let's just leave
it up to the lower layers
Libvirt nowadays will throw an explicit warning about this
exact situation. It doesn't guide people to virt-manager UI, but
then again it should be obscure enough that it doesn't warrant this
special corner case code to inform the user
Having this at set_uefi time complicates the domain XML building
machinery, where we don't want things to have osinfo access.
Rearrange it so that editing cases call this explicitly, and
the XML builder just deals with it at the set_defaults time
It's hard to validate whether something like --extra-args or
--initrd-inject is supported based on the command line arguments. It's
easier to let the installer.py figure it out because it's the
authoritative source
This adds a field in gsettings and preferences UI to enable
XML editing. It's off by default. The XML tab page is still visible,
but the textview is not editable, and there's a warning at the top:
XML editing is disabled in 'Preferences'.
Only enable it if you know what you are doing.
When the setting is enabled, the warning goes away and the textview
is editable. This puts a roadblock up for people that don't know what
they are doing, but still advertises the feature and keeps the
UI surface difference fairly small between on/off states.
Handling this is a bit different from other bits, because:
1) the <device> editing paradigm is unique. We need to replace the
device in line in the XML which is a new operation
2) the New VM customize pattern is tricky and needs lots of
special handling
The XML editor ui is a two tabbed notebook, one 'Details' tab
and one 'XML' tab. The latter has a gtksourceview and allows editing
the raw libvirt XML for whatever the selected object is.
API users will programmatically insert the xmleditor notebook into
their UI, with the existing UI under the details tab.
SupportCache.check_support(SUPPORT_FOOBAR, args) becomes
SupportCache.foobar(args)
And SupportCache absorbs the caching infrastructure from
VirtinstConnection.
For now we add some hackery to hide the API change from callers, but
this will be undone in the next patch
Will take a string of comma separated options which we can use to
tweak app behavior, for testing. Convert the existing --test-* options
to use the same abstraction internally. This will make it easier to
add new test options in the future
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
Whether we show something in the UI should be more dependent on
whether it's actually set in the XML, not some internal hardcoded
list which can go out of date.
Right now we overload the DEVICE column for non-device pages
like overview or memory. Add a separate column for KEY, and have
DEVICE==None for non-device pages
vmmVMWindow handles all the menuing, and coordinating between the
console, snapshots, and details panel. Simplifies the details
code a bit which will help when we add xmlediting
It's a mix of stuff libvirt already catches, UI sanity checking
like if user specified an empty field, and prompting for really
obscure corner cases. This stuff isn't important enough to carry
around all this code IMO
Name and forward mode config are always visible. ipv4, ipv6, and
domain name are under their own expanders which are collapsed by
default.
This will fit better with the XML editor pattern and reduce the
urge to squeeze more UI elements into the now smaller wizard
Rather than a mix of radio buttons and other combo boxes.
This follows the pattern we more commonly use in other UI, and
makes it easier to hide UI elements that aren't relevant for
specific choices, like the possibly large SR-IOV selector
This wizard is sufficiently obscure that I don't think it's
really valuable to try to explain networking concepts with
UI labels. If users don't know what they are trying to create
by using this wizard, there's no way we are going to adequately
explain to them what they are looking at. The example values
should be self explanatory enough anyways
This only applies for inter VM traffic when ipv6 networking is
disabled, which IMO is pretty obscure. If users want ipv6
connectivity, just enabling ipv6 will handle it appropriately
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
The current code already prefers the "display name" over the "name" of
each application; hence, use "name" only if the "display name" is not
available.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Use the non-deprecated g.inspect_list_applications2() call to list the
installed applications. It is available since libguestfs >= 1.20, which
is lower than the current requirement (i.e. 1.22).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Instead of passing around the raw results of
g.inspect_list_applications(), create an helper vmmInspectionApplication
object with the data of an inspected application that we use. This is
done for different reasons:
- when using the data, it is easier to use member variables instead of
looking up values in a dictionary
- we keep only the data needed, slightly lowering the memory/objects
used for the inspected applications
- it will be easier to switch from g.inspect_list_applications() to
g.inspect_list_applications2() without changing code outside the
inspection code
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Save the package format of a guest as part of its inspection data, so
later on it can be used to tweak other results (like the version of
installed packages).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
The old code basically always set filesystems_mounted to True, even when
no filesystems were mounted successfully, unless
g.inspect_get_mountpoints() failed (very unlikely).
Instead, set it when at least one filesystem is mounted; considering
that the first filesystem to be mounted is usually /, then failing to
mount it will usually prevent the mounting of the others. In any case,
we can try to extract data even when only / is mounted, which can work
depending on the mount points of the guest.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Rely on the Python 3 sorting facilities to sort the mount points using
a key based on the length of the mount point, doing the same effect as
the old compare function.
As side change required by this, enable python_return_dict on the
GuestFS handle, so we get proper hashes instead of lists. This requires
libguestfs 1.22, which is 6 years old by now (and other virt-manager
requires are way more recent than that).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
This block only catches failures in g.inspect_get_mountpoints(), as the
g.mount_ro() calls are already within own try/catch blocks. Considering
that:
- g.inspect_get_mountpoints() is a simple API to query one of the
results of the inspection, it is very unlikely that it fails
- the whole _inspect_vm function (that contains the inspection code) is
already run within an own try/catch block, so even a failure in
g.inspect_get_mountpoints() will not crash virt-manager
then just remove this extra try/catch block.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
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
By default we copy CPU security features to the guest if specific CPU
model is selected. However, this may break migration and will affect
performance of the guest. This adds an option to disable this default
behavior.
The checkbox is clickable only on x86 and only on host where we can
detect any CPU security features, otherwise a tooltip is set to notify
users that there is nothing to copy.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If user selects specific CPU model to be configured for guest we will
automatically add CPU security features to make sure that the guest is
not vulnerable to these CPU HW bugs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1582667
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
We will need to pass another variable into the setter so we cannot use
the property setter.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
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>
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>
Function do_we_default returns only if we want to default to clone disk
even if we know how to create default clone path. Only in case that the
storage pool is TYPE_DISK we don't know how to create default path and
we cannot default to clone that disk. In all other cases as ReadOnly
disk or Shareable and so on we can prepare the default path for user if
they decide to clone it.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1565106
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If user renames guest in VM details page before installation starts
there is no need to rename NVRAM file as well.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1667308
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When cloning a guest in virt-manager the GUI shows a list of disks and
select default cloning policy for every disk. For storage pools where
we know that cloning is not possible we should not select that option
as default one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463066
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@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>
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>
Operate only on @boot_order and @guest and not on @self. This allows
us to refactor this functionality in the next patch. Additionally,
simplify the used algorithm without functionality change.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Try to avoid self access since this function operates on the guest
definition only. This is needed for later refactoring as it will
reduce side-effects.
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>
The Python binding of libguestfs errors out in case any of the details
(e.g. summary, description) of an application are not proper UTF-8.
This seems a rare situation, which nevertheless causes the failure of
the inspection of a guest, making the rest of the metadata not used.
While these encoding issues are tackled, and fixed in python-libguestfs
(or libguestfs itself), gracefully handle the failure of
inspect_list_applications(), so at least the rest of the details of a
guest are used/shown.
When a VM is using interface type=network with a forward mode=bridge
network, on qemu domain startup the runtime XML will be changed to
type=bridge and both source/@bridge and source/@network will be filled
in, which breaks some assumptions virt-manager had internally.
Unfortunately this isn't easy to test with the unittest driver either.
https://bugzilla.redhat.com/show_bug.cgi?id=1669265
Pino Toscano