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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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>
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>
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 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 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>
This was raised here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
Quoting from that:
"""
virt-convert takes an ovf/ova or vmx file and spits
out libvirt XML. It started as a code drop a long time ago that could
translate back and forth between vmx, ovf, and virt-image, a long dead
appliance format. In 2014 I converted it to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't seem to do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO
"""
Nothing has changed since then, so here is the removal.
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
This is the old default, where we would try to determine a static
keymap value from host graphics config files, and set that in the
XML.
We haven't defaulted to this for a long time, setting a static keymap
is suboptimal generally, and the file parsing code is not up to date
for modern host config. So let's remove it
The hostkeymap module is now unused, so remove it and all the custom
testing for it.
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>
We shouldn't be validating against a static list of keymaps,
instead we should let libvirt or the hypervisor throw and error.
Also the accompanying code is about to be removed.
It's possible this will break command line usage for some users, like
if they were passing keymap=US and depending on our logic to lower()
it for them. I think this should be rare, and IMO it's acceptable to
tell users to just fix their command line, which should work correctly
with older versions too, so it should be a one time fix.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
My previous patch was misguided as pointed out by Pavel:
https://github.com/virt-manager/virt-manager/issues/73#issuecomment-574680435
And it was setting incorrect memory, which I missed because the tests
are busted here. Add a hack to work around that
Bump up the default to 1024, and print it, so the user can tell if
the default is not to their liking
Signed-off-by: Cole Robinson <crobinso@redhat.com>
AFAICT the driver doesn't really do anything with it, but libvirt
XML requires it. So just default to --memory 64
Fixes: #73
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to restore logging after calling the cli tools. Centralize
the logging reset behavior since we need that too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt is able to figure this out and it will make usage of the CLI
options more user-friendly.
For example if users wants to add a new pcie-root-port to existing VM
they have to figure out the latest controller index and call it like
this:
virt-xml \
--add-device \
--controller pci,model=pcie-root-port,index=$nextIndex \
$VM
After this change it will be simply:
virt-xml \
--add-device \
--controller pci,model=pcie-root-port \
$VM
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Cloud images all work nicely with text output, and it's likely
the preferred native way to connect to the guest vs graphical.
Plus it simplifies generated password copy+paste
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Now --cloud-init defaults to root-password-generate=yes,disable=yes.
Option for plaintext password given through the cli is completely removed.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
Tests now cover default --cloud-init behavior, and
root-password=(generate and given password),disable=no.
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
When running virt-install as root, user-login would be automatically set
to "root", causing an installation failure in the most part of the
distros (if not all of them).
In order to avoid such failures, let's raise a runtime error in case the
user-login used is "root".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
