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>
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>
Cole Robinson
Daniel Henrique Barboza
Han Han
Stefan Berger
Lily Nie