Always force a network selection. If we have to fall back to
manual bridge UI because nothing else exists, show a warning.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The versions we are warning about are all over 4 years old, and
these warnings were initially just informative to help users know
when the config wasn't going to work. Drop most of it. Still warn
in the UI when a VM misconfig will prevent spice GL from working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to wire up some craziness to make path permission
searching fail, but this is a critical area to get correct
so it is worth it
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I don't think many, if any, people are using virt-manager with
openvz. Drop the specific handling the filesystem UI, users can use
the raw XML editor if they need special behavior
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add data/urldetect with a bunch of distro tree content to trigger
full code coverage of virtinst/install/urldetect.py
Signed-off-by: Cole Robinson <crobinso@redhat.com>
osinfo library doesn't return data for these with the fedora 32
version, so it's hard to get coverage testing. Since we aren't
even using this code yet anyways, let's remove it until it is needed
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We want to skip these tests if previous tests failed or were skipped,
but current impl depends on unittest specifics. Move it to pytest
Signed-off-by: Cole Robinson <crobinso@redhat.com>
pytest invocations are now preferred. Leave plain `./setup.py test`
as a stub that errors and points to pytest.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Makes 'pytest' and 'pytest --cov' work for the standard tests.
uitests run with `pytest --uitests --cov=virtManager`.
test_urls.py, test_dist.py, test_inject.py need to be invoked like
pytest $PATH
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Use single strings with proper placeholders for texts, so there is no
need to join together bits of translated texts.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Change the label for a generic OS to "Generic OS", and making it
translatable.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Add a --iommu option to configure IOMMU parameters as described in
https://libvirt.org/formatdomain.html#elementsIommu
E.g. 'virt-install --iommu model=intel,driver.aw_bits=48,driver.iotlb=on ...'
will generate the following domain XML:
<devices>
<iommu model="intel">
<driver aw_bits="48" iotlb="on"/>
</iommu>
</devices>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
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>
Users are fond of using "--tpm /dev/tpm0" to create a TPM device
for their VMs. ppc64 users, however, are experiencing errors because
the default TPM model is 'tpm-tis', which does not work in ppc64, and
they need to specify 'model=tpm-spapr' to work around that.
This patch makes the default TPM model change to 'tpm-spapr' when
running virt-install on a ppc64 host. A new test was added in test_cli.py
to test this new condition. This also keeps the 100% coverage of
the tpm.py file.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
CC: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
CC: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
codespell complains that one of the asserts is a typo:
tests/test_xmlconfig.py:92: ba ==> by, be
Using single quote strings in that assert will make codespell
pass. For consistency, let's change all the strings in the
test to be single quoted.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This will avoid codespell flagging 'msdos' as a typo.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Ubuntu 20.04 has a new installer, which is yet not supported by
virt-install / osinfo-db, and this made ubuntu switch their URLs
for the old installer to current/legacy-images/... instead of
current/images/...
Let's adapt URL detect so it can deal with this new "legacy"
style.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.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>
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 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>
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>
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>
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>
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>
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>
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
This was originally added so we had stable paths in the XML. It's
not required anymore, and if it becomes an issue we should fix it
by scrubbing the compared xml
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 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're going to slightly change how the device is handled in
a minute, and we want to make sure we don't break existing
functionality while doing so.
Note that the existing singleton-config-* test cases already
provide coverage for both enabling and disabling the memory
balloon in virt-install.
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
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
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.
--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.
This adds a field in gsettings and preferences UI to enable
XML editing. It's off by default. The XML tab page is still visible,
but the textview is not editable, and there's a warning at the top:
XML editing is disabled in 'Preferences'.
Only enable it if you know what you are doing.
When the setting is enabled, the warning goes away and the textview
is editable. This puts a roadblock up for people that don't know what
they are doing, but still advertises the feature and keeps the
UI surface difference fairly small between on/off states.
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>
Rather than editing existing Intel domain capabilities by hand, use
capabilities from a real AMD HW. We're later going to use these to fill
in SEV platform specific data automatically.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
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
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
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 memory hotplug changes only work on libvirt 5.3.0, among a few
other pieces. Still do the XML compare but skip domain define if
the new check_version_define comparison fails.
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.
Cole Robinson