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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Rather than individual options for each possible hypervisor,
and annotations like 'remote' or 'session', just have it take a
fake URI to mock
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Googling for 'Graphics requested but DISPLAY is not set' shows there's
some confusion about virt-install's behavior in this area. This gives
more output in several related cases about what commands we are
running and the state of the VM
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently if the path isn't managed on a remote connection we
treat it as file. Add this simple heuristic to improve the common
case.
https://bugzilla.redhat.com/show_bug.cgi?id=1726202
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>
This reworks the existing code to never have storage_backend = None,
instead carrying around a stub class, and resolving the actual
storage info when necessary. This makes the logic easier to follow.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The goal of this was to handle the case of a new libvirt bus that
we didn't know the prefix for. I suspect all new buses will in practice
use the 'sd' prefix, so this will never trigger
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>
The Guest code isn't triggerable because of the way the cli code
was invoking it, as a <memballoon> device would always be added.
Because libvirt accepts model=none, and that's what '--memballoon none'
will translate to anyways, we don't need any special handling here
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This incorrectly always evaluates to True. But no one ever complained
so let's keep that behavior the same
Signed-off-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 checking is overly involved, keepAlive is not an essential
feature, so just log an error if it fails
Signed-off-by: Cole Robinson <crobinso@redhat.com>
__getattr__ is only called when an attr is not already found
in __dict__, so this path will never trigger
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Our fallback implementation is the same as glib for all usage we
care about, so don't bother with calling glib
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>
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.
This puts all the default resource setting in one place, and the
only place that was depending on it, as virt-manager explicitly sets
the values on its own. This will be used in future patches to add
more default setup and report the values to the user
These include platform checks - libvirt & QEMU - as well as
configuration - SEV is only supported with UEFI.
Another configuration requirement made in this patch is Q35 machine,
since ADM recommends Q35 in their setups even though SEV can work with
the legacy PC machine type, but we'd have to turn on
virtio-non-transitional for all virtio devices with some other potential
pitfalls along the way.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The data in question are 'cbitpos' denoting which addressing bit is the
encryption bit and 'reduced_phys_bits' denoting how many physical
address space we lose by turning on the encryption. Both of these are
hypervisor dependent and thus will be the same for all the guest
residing on the same host, but need to be specified for future migration
purposes.
But given we can probe them from domain capabilities, we don't need the
user to provide them and thus enhancing cli user experience. This
requires a new _SEV domaincapabilities XML class to be created so that
we can query the specific properties.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Policy is a 4-byte bitfield used to turn on/off certain behaviour within
the SEV firmware. For a detailed table of supported flags, see
https://libvirt.org/formatdomain.html#launchSecurity.
Most of the flags are related to advanced features (some of them don't
even exist at the moment), except for the first 2 bits which determine
whether debug mode should be turned on and whether the same key should
be used to encrypt memory of multiple guests respectively.
>From security POV, most users will probably want separate keys for
individual guests, thus the value 0x03 was selected as the policy
default.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Introduce both the launchSecurity XML and parser classes. While at it,
add launchSecurity as a property instance to the Guest class too.
The parser requires the 'type' argument to be mandatory since in the
future it will determine different code paths, therefore
'--launchSecurity foo=bar' is incorrect.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The way the code was nested, we skipped calling validate() on
XMLChildProperty is_single objects. There's no reason to do that,
so adjust it.
We need to do some hasattr checking here, because --os-variant and
--location objects aren't XMLBuilders with validate defined. That's
really an issue of having XMLBuilder assumptions baked into the
generic CLI parsing infrastructure. Unwinding that is for another day
On Fedora mkisofs and genisoimage are identical and shipped in the
same package. On debian only genisoimage is shipped due to some
historical weirdness or licensing dispute or something. So just
prefer the genisoimage naming
We are implicitly depending on random dict ordering for what
order we process Distro matching. Our test suite mocking and
different debian ordering revealed a case we could be trying to
run a regex against None. Fix it. The dict ordering issue will
be fixed separately
And pass it down to treemedia, which acts on our script wrapper
object. This is conceptually a bit simpler because we can see in
one place what data feeds the script build process, depending on
installer props
* Make all API calls go through the _OsMedia object
* Move most of the unattended specific processing to unattended.py
* Rename requires_internet to is_netinst to clarify what it is checking
The reason this was done, is because we need to inject files with
certain names into the initrd/cdrom media so the guest OS can find
them, but our injection infrastructure didn't have the knowledge
necessary to rename files at injection time.
Having to deal with the subdir complicates cleanup and unattended
data generation, so let's do away with it. Teach the injection
bits about renaming, and adjust all the related bits to use
standard tempdirs
- Break out the installer* unattended prep to its own function
- Move logging into common unattended call
- Use libosinfo APIs to generate script str, then we write it
- Move commandline lookup to installertreemedia
- Rename path->scriptpath for clarity
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
Instead of using "floppy" as the way to perform unattended installations
for Windoes, let's prefer using "cdrom" instead.
The main reasons behind this change are:
- VMs using q35 may have floppy device disabled in some systems;
- We can drop mstools dependency;
Generating the ISO depends on genisofs, tho. However, it's not a big
deal as genisofs is already a virt-manager dependency.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Together with the temporary files removal, let's also remove the
directories created to store those files.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similarly to what's already done in installertreeinfo.py, let's log when
removing the files used during the unattended installation.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's just use mktemp() as done in several other places and avoid the
risk of having the content of the folder overwritten in case of parallel
installations.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The 'secure' option is processed after the model is already set.
CPU security options are resolved while setting CPU model so we need
to know the 'secure' option value before we set the CPU model.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The checking is hard to get right because there are many ways to
specify storage. Rework it to try to determine if we should
create storage from disk XML contents
The <domain> XML it alters is called <seclabel>, and security is
really generic sounding. Add the alias and switch the documentation
over to prefer --seclabel
Add some cli infrastructure and testsuite magic to track whether
a cli suboption and cli alias is triggered. This makes it harder
to accidentally add cli option regressions.
We make some exceptions for shared options, requiring them to only
be tested once, otherwise trying to test all address options for
every device will be a giant pain.
There can be more than 1 <memoryBacking><hugepages><page> element.
Adjust the cli options to match:
- hugepages.page[0-9]*.size
- hugepages.page[0-9]*.unit
- hugepages.page[0-9]*.nodeset
This adds the following suboptions to configure the <domain><vcpus>
list:
- vcpus.vcpu[0-9]*.id
- vcpus.vcpu[0-9]*.enabled
- vcpus.vcpu[0-9]*.hotpluggable
- vcpus.vcpu[0-9]*.order
The latter is for triggering <genid/> bool XML, which tells libvirt
to auto-allocate a UUID. The cli isn't really XML conformant but
I can't think of anything better that is self advertising
There is a new security feature 'md-clear' that mitigates recent CPU
Microarchitectural Store Buffer Data vulnerability.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If the optstr is "host" or "emulate" the optdict['type'] was already set
to the proper value so that condition is useless and we should set the
default optdict['type'] only if there was no type specified by user,
otherwise it is overwrite by our 'smbios' default.
In addition if invalid type is specified let libvirt to do the error
checking.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1707379
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Add char source arguments to all users:
--serial
--parallel
--console
--channel
--smartcard
--rng
--redirdev
Not all source options apply to all types, but libvirt doesn't
really discriminate, so we should do the same.
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* backend_connect_host -> backend.source.connect_host
* backend_connect_service -> backend.source.connect_service
* backend_host -> backend.source.host
* backend_mode -> backend.source.mode
* backend_service -> backend.source.service
* backend_type -> backend.type
* rate_bytes -> rate.bytes
* rate_period -> rate.period
'type', and 'device' are kept as advertised options,
due to them being commonly specified and documented
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* protocol -> protocol.type
* target_address -> target.address
* name -> target.name
* target_type -> target.type
'host', 'path', 'mode', and 'bind_host' are kept as advertised options,
due to them being commonly specified and documented
This violates our typical XML hierarchy, but that's how it's modeled
internally in libvirt, and these properties are shared among all
charsource users.
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
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
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* baseBoard_asset -> baseBoard.asset
* baseBoard_location -> baseBoard.location
* baseBoard_manufacturer -> baseBoard.manufacturer
* baseBoard_product -> baseBoard.product
* baseBoard_serial -> baseBoard.serial
* baseBoard_version -> baseBoard.version
* bios_date -> bios.date
* bios_release -> bios.release
* bios_vendor -> bios.vendor
* bios_version -> bios.version
* system_family -> system.family
* system_manufacturer -> system.manufacturer
* system_product -> system.product
* system_serial -> system.serial
* system_sku -> system.sku
* system_uuid -> system.uuid
* system_version -> system.version
In truth this does not accurately represent the XML either, which
uses a generic <entry name='FOO'>BAR</entry> syntax. We should
expose that raw config on the cli, but also provide these convenience
options too, so using '.' here is still useful to be consistent
with new style opt names.
