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>
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>
Saves us possibly hammering the logs if this goes wrong. We are
about to start using it more in virt-manager
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>
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>
* 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>
All the major hypervisor drivers have supported listAllDomains
since rhel6 vintage libvirt. Most other driver types have had the APIs
since their introduction, or for just as long.
I will be surprised if this affects anyone in any material way
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>
As osinfo-db introduced the first usage of reg-login, let's also
add support for such option when using --unattended.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's check for both genisoimage and mkisofs as some distros will ship
mkisofs without linking it to genisoimage, as OpenSUSE Leap 15.1 does.
And, I know, genisoimage is a requirement of the project. However, it's
not packaged on OpenSUSE Leap 15.1 while mkisofs is present there.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Like if /bin/true is missing, as it was on freebsd. Use /bin/test
instead which appears to have a higher likelyhood of existing
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>
* Ensure files are cleaned up if we fail mid run
* Ensure temp user-data and meta-data files are cleaned up
* Move dest file naming into cloudinit.py
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fixed:
- Added a do_log flag to print_stdout(), to avoid logging of printed random password.
- Excluded timeout in virt-install from testing
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
Password expiration happens in case of one time random password generation.
When user provides password from file, don't expire the password.
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.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>
Cli option to permanently disable cloud-init after first boot by user request.
Handled so that bare --cloud-init defaults to --cloud-init root-password=generate,disable=yes.
Signed-off-by: Athina Plaskasoviti <athina.plaskasoviti@gmail.com>
Currently, the kernel_url_arg is get based on the cached data. However,
when the cached data is created, the store is already set to a "generic"
distro and the os_variant is not respected when getting the
kernel_url_arg.
In order to avoid ignoring os_variant when looking up the kernel_url_arg,
let's also take into the consideration the the os_variant passed via
command line, which was used to set Guest's osinfo name, returning then
the expected value to the caller.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.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>
Let's allow setting the login of the guest user.
Using the user from the system is a quite good fallback, but would break
unattended installations when running virt-install as root. Thus, for
those cases, it makes sense to have the option of setting the user
login.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
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>
We need to check against None, which is the initial value, otherwise
a host with none of the security features present will repeatedly poll
libvirt baseline APIs
Signed-off-by: Cole Robinson <crobinso@redhat.com>
With libvirt-python >= 4.4.0 and libvirt < 4.4.0 we would receive
libvirt.libvirtError exception because the python binding knows about
the function but it's not supported by libvirt. However, in case that
the python binding is older then 4.4.0 it will raise AttributeError
because the function is not implemented in python binding as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
domcapabilities already handles disk and hostdev. Let's add support for
getting video devices as well.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a new API to set extra drivers that can be used during
installation time when performing unattended installations. This is
needed for pre-installing virtio-win drivers on Windows guests.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's download and install the pre-installable drivers, if they're
available.
The reason we're only dealing with pre-installable drivers here is that
post-installable drivers would have to keep the unattended is available
accross reboots, resulting in a file that can't be cleaned up at this
point.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similarly to what has been done for _device_filter(), let's add
"extra_args" parameter to support_* methods so we can pass them down to
_device_filter().
Only supports_virtio* methos would actually need the extra argument, but
let's be consistent here and add it to all supports_* methods.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add "extra_devs" to _device_filter() so we can pass a list of
devices which can be used by an OS but are not part of the distro / OS
itself.
By doing this, we also expand the _device_filter() check and take those
into account when they're passed.
That's exactly the case of pre-installable drivers for Microsoft
Windows.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a new method to get the devices which are supported when
taking advantage of a pre / post installable drivers.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This will be used by unattended installations in order to download both
pre & post installable drivers.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The post-installable drivers provided by osinfo-db are merely agents,
which are not a blocker for an installation to succeed using virtio &
having a bootable guest.
Let's add this method as a counter part of supports_unattended_drivers()
and use it in the future, when we re-work the installation code of
virt-install and are able to perform installations of MSIs.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
supported_unattended_drivers() was originally added as a way to tell
whether a guest could support pre & post installable drivers.
This is wrong for two reasons:
- virt-install cannot deal with post-installable drivers/agents;
- pre-installable drivers are the only ones needed in order to perform
an unattended installation taking advantage of virtio-win drivers;
Knowing that, let's only check for pre-installable drivers in
supported_unattended_drivers().
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
osinfo-db may contain files pointing to local paths, which will have the
format 'file:///usr/share/...'.
With the current code, virt-install would just bail as it doesn't
understand the 'file://' schema. Let's start using urllib (which is
already imported in the very same file) and parse the URL so both
'file:///usr/share/...' and '/usr/share/...' would work.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some installations (Microsoft Windows was the problematic one here) will
bail if the Computer's name / hostname contains one of the following
characterers: "[{|}~[\\]^':; <=>?@!\"#$%`()+/.,*&]".
Let's take a safe path and ensure that we never set those, replacing
them by "-".
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As some OSes, as Fedora, have variants (which we rely to be standardised
on osinfo-db side), let's select the most appropriate variant according
to the selected profile of the unattended installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some OSes, as Fedora, have variants (which we rely to be standardised on
osinfo-db side), which we can use to return the most generic tree
possible, in case no profile is specified, in order to avoid failing to
install a "Workstation" system because a "Server" variant tree was used.
https://bugzilla.redhat.com/show_bug.cgi?id=1749865
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
QEMU version 2.12.1 introduced a performance feature under commit
be7773268d98 ("target-i386: add KVM_HINTS_DEDICATED performance hint").
Support for this performance hint was added in libvirt 5.7.0 by commit
cb12c59dac04 ("qemu: support for kvm-hint-dedicated performance hint").
This patch extends virt-install's existing --features option to insert the
appropriate XML into the guest definition if this feature is specified
on the command line.
E.g. --features='kvm.hint-dedicated.state=on' would result
in the following XML:
<features>
...
<kvm>
<hint-dedicated state='on'/>
</kvm>
...
</features>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
Let's add a method which tells us whether pre & post installable drivers
are supported when performing unattended installations.
This is going to help us in the future in order to force virtio-win
usage when unattended installing guests which support it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add two new methods to get the pre & post installable drivers'
location, returning a list of URLs (strings).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add two new *private* methods to get the pre & post installable
drivers, returning a list of OsinfoDeviceDrivers;
Those are going to be used later on this series in order to get the
drivers' locations.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
acquireFile method receives an optional "fullurl" argument. In case it's
not passed, its value is set as the same value of the filename. However,
when fullurl is passed, it should be used and not overriden by the
filename, otherwise fetcher.acquireFile() will just bail.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
While downloading really small files, on some file systems, the files
may not be flushed on time for whatever reason they've been downloaded.
This issue was noticed after trying to perform unattended installations
and noticing that some files, particularly really small ones, where just
empty.
While the original issue would be fixed by doing the flush on
_HTTPURLFetcher::_write(), let's also force it on _URLFetcher::_write()
to do the same.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Windows' unattended installations have more than one installation script
in order to perform a "post" installation of some drivers
(spice-guest-tools, actually).
In order to do so, let's:
- Change unattended::_lookup_rawscript() to return a list of scripts;
- And also rename it to _lookup_rawscripts();
- Change unattended::prepare_install_script to return a list of scripts;
- And also rename it to prepare_install_scripts
- Change installer::_prepare_unattended_data() to deal with a list of
scripts;
- And also do the "renaming" changes accordingly;
- Change installertreeinfo::_prepare_unattended_data() to deal with a
list of scripts;
- And also do the "renaming" changes accordingly;
- Mind that this change is not exactly needed as Linux unattended
installations have only one install script. However, the change has
been done ir order to be consitent with the changes done in the
installer;
- Change installertreeinfo::_prepare_kernel_args() to deal with a list
of scripts;
- And also do the "renaming" changes accordingly;
- As the changes above, this one is not exactly needed for the very
same reason;
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some osed have multiple short-ids, like debian10 also has debianbuster.
Use the API if it's available. This will make it easier to remove
our back compat aliases eventually
Move thread callback outside the StorageVolume class, so we are
forced to explicitly pass in every bit it may act on. Ensure we
always cancel and clean up the thread
Let's use identify_tree(), which is part of libosinfo v1.6.0 release,
instead of using guess_os_from_tree().
The API has been implemented on libosinfo in order to be consistent with
what was already done for medias.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's use generate_for_tree() and generate_command_line_for_tree()
methods whenever it's possible.
This method, similarly to generate_for_media() and
generate_command_line_for_media() will take an OsinfoTree as parameter
and will use its info in order to better decide how to properly generate
the install-script and kernel command-line.
It's important to mention that those APIs are part of libosinfo v1.6.0
release and that's the reason the check for them has been added.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Later on, it'll be used to generate the install-script and the kernel
command-line based on the specific tree being used.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's allow to get the tree object from InstallerTreeMedia class.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's get the _OsTree object and have it added to the _LocationData
class.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a method that allows the tree object to be retrieved from the
_DistroTree class.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As already done for _OsMedia, let's store the _OsTree object detected
as it'll be used later on in order to improve the installer script and
the kernel command line used for (tree based) unattended installations.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of returning an OsinfoTree, let's be consistent with what we
already do in guess_os_from_iso() and return our internal _OsTree
object.
This change doesn't affect any code as the only place using it doesn't
care about the returned tree object.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similarly to the _OsMedia() class, let's create a _OsTree() class which,
at least for now, has only one method that returns the OsinfoTree
object.
Although this class & method are not extrictly needed, having them makes
the code more consistent.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's set "media" as installation source for all the ISOs, even the
net-installer ones, as this can be dealt with on osinfo-db side.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's use generate_for_media() generate_command_line_for_media() methods
whenever it's possible.
This method, differently from generate() and generate_command_line(),
will take an OsinfoMedia as parameter and will use its info in order to
better decide how to properly generate the install-script and the kernel
command-line.
It's important to mention that those APIs were released as part of
libosinfo v0.2.12, from May 26th, 2015. Knowing it's out for 4+ years
from the moment of this comment, I'm taken the path as not checking
whether the libosinfo used has this API or not.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's pass the OsinfoMedia object down to the OSInstallScript class so
it can be used, later on, to generate the install-script and kernel
command-line specifically for the media being used.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a way to get the OsinfoMedia from the _OsMedia class. It's
going to be needed in order to properly generate the command line for
the unattended installations, when doing an installation from a media.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of a creating a new Config object and setting and the needed
fields, let's just save the original user & admin passwords, set the
"[SCRUBBLED]" one for generating the debug output, and reset the
original values after that.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Logging user & admin passwords in the command-line is a security issue,
let's avoid doing so by:
- Not printing the values set by the user when setting up the
install-script config file;
- Removing the values used in the install-scripts, when printing their
content;
'CVE-2019-10183' has been assigned to the virt-install --unattended
admin-password=xxx disclosure issue.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's not expose the user/root password in the CLI and, instead, let's
rely on a file passed by the admin and read the password from there.
'CVE-2019-10183' has been assigned to the virt-install --unattended
admin-password=xxx disclosure issue.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
libvirt already does this for pretty much all QEMU guests, but
ARM virt guests for example don't get a memory balloon by default
at that level of the stack.
virt-manager is in a good position to make sure defaults are
consistent across architectures, and there's no downside in having
the device in the XML passed to libvirt anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We want to start adding a memory balloon automatically to
guests, but we also need to make sure that it can be explicitly
disabled at the user's request.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
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
This helps us break that virt-install dependency: parse cli to get
arch/machine info, cli requests uefi, uefi needs to know arch machine
info. Instead just make the 'uefi' bit set a flag, that we resolve
in Guest.set_defaults once we have all the info we need.
ALLSTORES was implicitly using dict() ordering. This exposed
a bug in our code on debian ci which was nice, but it should
be deterministic. Hardcode the ordering
Not sure I want to go down that route if we can avoid it. Instead
just fold the full_id support into the existing option handling.
Streamline the OSVariantData usage throughout the cli tools
Replace the unreleased --os-variant OSNAME,install=location with just
--install OSNAME
Unwind the --unattended dependency on upfront --os-variant while
we are at it, since they are all intertwined. Now we can just do:
virt-install --install OSNAME
and
virt-install --install OSNAME --unattended
We set this to True in virt-install, which will cause an explicit
error to be thrown if some part of the cli parser tries to access
osinfo before it's been set, because then we have a circular dependency
between cli config -> installer -> osinfo -> cli config
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
Add an explicit no_install to Installer to encode that the user is
not expecting an install phase. Use that to determine later if any
install options were specified. This saves later code from having
to deal with installer=None, and is the basis for further clarifications
This reverts commit 66fe00ddee.
Turns out it's not that simple. Indeed libvirt sets the default
when no <vcpus> XML is present, but if you do --vcpus cpuset=X
libvirt will error that there's no vcpu value set. So for back
compat and generate safety let's keep setting it.
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
--install kernel_args=X acts like --extra-args. If
kernel_args_overwrite=yes is also specified, it overwrites whatever
default kernel args we would have used for the install method.
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.
It was disabled with commit 2aca20141e back in 2015, but
these days we have it enabled for all other architectures and
there doesn't seem to be a good reason for s390x to keep being
the outlier.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This uses the same logic as virt-manager. The name is mostly
derived from --os-variant naming, but we have fallback defaults too.
Print the name to stdout so users are informed about what we are
doing.
Cole Robinson