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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
- device_path -> device.path
- device_weight -> device.weight
Sort out the memory property naming ambiguity on the command line.
* memory -> currentMemory
* maxmemory -> memory
* hotplugmemorymax -> maxMemory
* hotplugmemoryslots -> maxMemory.slots
To maintain back compat, we need to do some funky handling with
memory and maxmemory values. Basically if currentMemory is specfied,
we interpret them as new style, otherwise preserve the old behavior.
If an OS has a <minimum> resources section, and a <recommended>
resources section, but there's a field in the former that isn't in
the latter, currently we throw out the former field entirely. This
is the case for n-cpus for a few OS. Instead we should be using
the <minimum> ncpus value. This changes the default <vcpu> value
for a quite a few test cases.
Right now we have:
* memory -> ./currentMemory
* maxmem -> ./memory
* hotplugmaxmem -> ./maxMemory
Which is just a mess to know what we might be really setting behind
the scenes. Rename the properties to match the XML element name, and
adjust all users to the new names. cli options aren't changed though
Rather than associate them per virt argument. It's less of a clean
fit this way, but I think it will make it less likely that aliases
are cargo culted around and added unnecessarily
- Put clearxml at the very top, because it's a bit special and I
don't like it mixed in with the interesting settings
- Put address.X at the top, after clearxml, because there's a lot of
settings and I'd like to keep them away from the users' visual field
Turns out propname is used for virt-xml device matching, even if we
have a cb, so it's useful to specify if the cliname truly maps to
a single propname. Add a programming error exception to try and
explain this situation so it doesn't slip in by accident.
Seems like a bad idea to define our own double underscore function,
incase a future python version wants to use that name.
Tweak some minor InitClass details while we are in the area
This is some extra validation to catch some char opt combos that
libvirt doesn't explicitly reject. It's not really interesting and
dropping it simplifies the cli parsing
Every add_arg call needs a cliname (the option name on the command
line), but not all calls need an attrname (the propery/method name
of the virtinst API object) because they rely on a callback for
less simple functionality.
So swap the ordering so that cliname is the first argument. Drop
redundant attrname=None arguments and validate that either attrname
or cb=X is passed.
We pretty much require a referenced storage pool to be running if
it's intended to be used as a virt-install or virt-manager requested
disk. So add a helper to start a pool if needed and optionally refresh
it
The original code created a new list which had True/False items. The
only case where the returned value would be False is for empty list
which never happens in real environment.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
For CPU modes other then "custom" there is no model so we should not
check the suffix of model name.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
VM configured with mode="host-model" will have the CPU definition
expanded once the VM is started. Libvirt will try to use the closest
CPU model with some features enabled/disabled.
The issue is that there are some models that include spec-ctrl or ibpb
features and they will not appear in the explicit list of features and
virt-manager will not correctly detect if all security features are
enabled or not. As a workaround we can check the suffix of CPU model to
figure out which security features are enabled by the model itself.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If USB support is available, we can use USB input devices too.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Unlike other features we have enabled earlier, this one requires
version checks because RISC-V guests have only started using PCI
by default very recently, and we can't have USB without PCI.
More specifically, we need QEMU commit d6c1bd4a2237 (included
in 4.0.0) and libvirt commit 7c48fb08e0cd (included in 5.3.0).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
QXL, on the other hand, is still x86-only for some reason.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The default machine at the QEMU level is spike_v1.10, but most
people will really want to use the virt machine type instead.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
By default we copy CPU security features to the guest if specific CPU
model is selected. However, this may break migration and will affect
performance of the guest. This adds an option to disable this default
behavior.
The checkbox is clickable only on x86 and only on host where we can
detect any CPU security features, otherwise a tooltip is set to notify
users that there is nothing to copy.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We will call this function multiple times so it makes sense to cache the
result so we don't have to call libvirt APIs every time we will check
what security features are available on the host.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
