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.
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
This will allow users to override the default behavior of virt-install
which copies CPU security features available on the host to the guest
XML if specific CPU model is configured.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Using 'virt-install --disk size=X' implicitly uses pool=default. If
a pool named 'default' exists we use that; if not, and a pool using
the default path exists under a different name, we attempt to use
that as well, and if that doesn't exist, we create pool=default
The second case is broken, so if there's no pool=default and eg.
pool=FOO points to /var/lib/libvirt/images, we still attempt to
look up pool=default which understandably fails
https://bugzilla.redhat.com/show_bug.cgi?id=1692489
libvirt commit 09eb1ae0 added support for a new 'xenbus' controller
type. Add support for the controller in virtinst, including support
for the maxGrantFrames attribute.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
If user selects specific CPU model to be configured for guest we will
automatically add CPU security features to make sure that the guest is
not vulnerable to these CPU HW bugs.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1582667
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
We will need to pass another variable into the setter so we cannot use
the property setter.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
<controller> can have additional <driver> sub element with queues as property,
which is currently not exposed via virt-install. This commit exposes this option
similar to queues in network configuration.
(crobinso: add test case)
Our support.py check is not exhaustive based on libvirt code checking.
Don't reject this case so users have a chance to make it work. The
support check is really more valuable in the UI where we can screw
things up easier.
Use the newly introduced method `reorder_boot_order` for setting
the boot index of a device. This ensures that all other boot order
values of domain guest definition are adjusted accordingly.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Add a check if device boot order is supported to
Parser(Network|Disk|Redirdev|...) and throw an exception if not.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Refactor get_prop since it will be used in the next patches at other
places as well.
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
--unattended is currently a no-op parameter that will be used to perform
unattended installations.
For now, if someone tries to use --unattended virt-install will fail as
the option is still not supported.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This fixes virt-xml to return an XML for command:
virt-xml --build-xml --boot os_type=hvm
The VirtCLIParser.parse() expects the _parse() method to return
the parsed object.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Instead of duplicating the code into CLI and GUI move it into graphics
device file which is used from both places. This also fixes a bug in
virt-xml where changing listen to address was not working.
This also changes behavior to always configure one listen type when
using CLI listen option or GUI. If user wants to modify only specific
listen type they can use listens[] options from CLI.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1565968
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The new "install" parameter receives "location|cdrom" and will be used,
at least for now, to automatically get the URL location of an OS from
osinfo-db.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Add kernel= and initrd= --location suboptions. These can be
used to override the default kernel/initrd and specify new
paths, relative to LOCATION.
For example, if you have an ISO that libosinfo doesn't know
about called my-unknown.iso, with a kernel at 'kernel/fookernel'
and initrd at +'kernel/fooinitrd', you can make this work with:
--location my-unknown.iso,kernel=kernel/fookernel,initrd=kernel/fooinitrd
