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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There's valid cases where a VM can be defined with a conflicting MAC
address. Prior to ebd6091cc8e4 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>
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>
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 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>
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>
