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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Via the virt-manager UI we aren't converting relative path to
absolute path, even though we do it internally when needed.
We were benefiting from this in the test suite in some ways, so we
need to adjust tests to strip out the dev dir on XML comparison
Signed-off-by: Cole Robinson <crobinso@redhat.com>
And move the path to not be rooted in /dev, which doesn't make
sense for a directory pool, and triggers some special /dev handling
in virtinst that we don't want in the common testing path.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It _is_ type=logical, so make it clear in the naming. Plus we
already have a type=disk pool named pool-disk
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the power of --xml to individual device options. For example
this makes it easier to make custom XML changes for a single --disk
device from both virt-install and virt-xml
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a virt-xml option to refresh a VM to use the latest machine
type version for the machine type it's currently using. Ex:
pseries-2.11 -> pseries
pc-q35-5.0 -> q35
This is useful for when qemu deprecates and removes the machine type
out from under you, or to pick up bug fixes.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt defaults to PCIe for arm32/aarch64 and riscv -M virt too.
Rename q35_pcie_root_ports to num_pcie_root_ports and extend the
logic to those archs too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's generally not as valuable for non-x86 where we don't have the
history of supporting non-virtio OSes, but as time goes on it will
likely become more relevant for non-x86 arches, so let's make this
change now to get ahead of it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Move most xml suboption testing to many-devices test
- Clarify every specific bit we are testing in the singleton tests
- Consolidate/drop/reduce a lot of tests
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The code previously was just encoding the same defaults as libvirt,
which doesn't really add anything.
Instead, let's prefer type='emulator' model='tpm-crb', which
gives the most modern virtualization friendly config. When we don't
know if that will work, we mostly leave things up to libvirt to fill
in.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add extra PCIe root ports to enable q35 device hotplug to work out
of the box. A typical modern linux guest has 7-8 PCI devices added
by default, so this gives plenty of wiggle room.
The smart thing to do would be to count the attached PCI devices
and add 4-5 extra, but that takes more work and isn't trivial.
The number can be overridden on the cli with:
--controller q35_pcie_root_ports=X
Use =0 to go back to the old behavior.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
host-copy was the old default, but it's fundamentally flawed. Since
we switched to host-model default a few years back, it's not advertised
in the docs or selectable via virt-manager any more.
Have it print a warning and invoke host-model-only
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This was previously discussed here:
https://listman.redhat.com/archives/virt-tools-list/2020-September/msg00017.html
For the x86 + hvm case, failure to specify an --osinfo/--os-variant
OS, and failure to detect an OS from install media, will now throw
a big error:
```
--os-variant/--osinfo OS name is required, but no value was
set or detected.
This is now a fatal error. Specifying an OS name is required
for modern, performant, and secure virtual machine defaults.
If you expected virt-install to detect an OS name from the
install media, you can set a fallback OS name with:
--osinfo detect=on,name=OSNAME
You can see a full list of possible OS name values with:
virt-install --osinfo list
If your Linux distro is not listed, try one of generic values
such as: linux2020, linux2018, linux2016
If you just need to get the old behavior back, you can use:
--osinfo detect=on,require=off
Or export VIRTINSTALL_OSINFO_DISABLE_REQUIRE=1
```
The thread goes into more detail, but basically, for x86 VMs at least,
it's unlikely you will _ever_ want the default 'generic' behavior,
which gives gives no virtio, no PCIe, no usb3, IDE disks, slow
network devices, etc.
Many people use virt-install in scripts and CI, and this may now
cause breakage. The environment variable is there to help them
get things back to normal as quick as possible, but it will still
noisy up their logs with the warning to hopefully get them to make
a useful change to their virt-install invocations.
This is limited to x86, since that's where most of our defaults
historically differ, and where we can depend on libosinfo to give
the most accurate device info. This may be relevant to change for
other KVM architectures in the future.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We are about to change the some defaults around os handling. Let's
start recommending the nicer named --osinfo more, since new error
messages are going to promote it a bit as well
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I'm still seeing blog posts that recommend using
--os-type linux --os-variant XXX
Which has been a no op for a long time but is mostly harmless.
Current git would make this an error condition, but that's too
disruptive IMO. Just print a warning
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical tool for this is `osinfo-query os`, which we still
reference in the man pages and in the list output.
However, we are about to make missing --os-variant fatal for common
usage, and I don't want to force users to install an extra tool just
to figure out what an acceptable --os-variant value is.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This recommendation came from an internal discussion. The cases are
* For block storage. This means guest requests are passed through
to the host device, which seems a more reasonable default than
ignoring them
* For sparse disk images we will create. discard=unmap helps preserve
the sparseness of the disk image. If a user requests non-sparse, they
are likely more concerned with performance than saving disk space,
so we leave the default as is. We limit this to disk images we will
create, since that's the easiest case to check, and it's less clear
if we should change the behavior here for an arbitrary existing
disk image.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We were not correctly accounting for the internal representation of
some fields, and just trying to a string comparison. We need to be
a bit smarter than that
Fixes: https://github.com/virt-manager/virt-manager/issues/356
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The bare metal world is moving to a situation where UEFI is going to be
the only supported firmware and there will be a strong expectation for
TPM and SecureBoot support.
With this in mind, if we're enabling UEFI on a VM, it makes sense to
also provide a TPM alongside it.
Since this requires swtpm to be installed we can't do this
unconditionally. The forthcoming libvirt release expands the domain
capabilities to report whether TPMs are supported, so we check that.
The user can disable the default TPM by requesting --tpm none
https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The product of sockets * dies * cores * threads must be equal to the
vCPU count. While libvirt and QEMU will report this error scenario,
it makes sense to catch it in virt-install, so we can test our local
logic for setting defaults for topology.
This exposes some inconsistent configurations in the test suite.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Although using --cpu topology.XXX is the preferred way to set topology,
it is still possible via the --vcpus parameter. For consistency, this
should support the full set of parameters, so dies needs to be added.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The code comment suggests removing the aliases after a year. It has
now been three years, so it is time for them to go.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add the ability to set the ioapic driver using the --features argument:
$ virt-install --features ioapic.driver=qemu ...
This results in the following xml:
<features>
...
<ioapic driver="qemu"/>
</features>
This is required in order to install a guest with >255 cpus. Such a
configuration requires an iommu with extended interrupt mode enabled,
which in turn requires IOMMU interrupt remapping to be enabled, which in
turn requires a split I/O APIC.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
The code was only checking the manual approach to enabling UEFI, not the
modern automatic approach.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt now validates that all <hostdev> elements refer to distinct host
devices. The test suite violates that constraint by trying to build a
new guest with the same USB devices added to the guest twice, to
validate the various host device syntax options.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Libvirt now validates that all <hostdev> elements refer to distinct host
devices. The test suite violates that constraint by trying to hot-add a
device that alreadye exists in the config.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Some test scenarios need to make sure different mac addresses would
_not_ be used in normal operations, but the test suite always generates
the same value. Add some hacks to let the test suite override the
default behavior and use incrementing addresses
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The libvirt test driver doesn't support hotplug. Add an env variable
to ignore failure, so we can get better test coverage here
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This includes support for the following options:
* numa.interconnects.latency[0-9]*.initiator
* numa.interconnects.latency[0-9]*.target
* numa.interconnects.latency[0-9]*.cache
* numa.interconnects.latency[0-9]*.type
* numa.interconnects.latency[0-9]*.value
* numa.interconnects.latency[0-9]*.unit
* The same suboptions for `numa.interconnects.bandwith[0-9]*`
Note that the cache= attribute is only explicitly defined for <latency>
nodes in the documentation. However, since <latency> and <bandwidth>
nodes are otherwise identical, the docs also don't explicitly forbid it
for <bandwidth> nodes, and libvirt happily accepts XML that does specify
it for for <bandwidth> nodes, this implements the cache= attribute for
<bandwidth> elements as well.
This includes support for the following options:
* numa.cell[0-9]*.cache[0-9]*.level
* numa.cell[0-9]*.cache[0-9]*.associativity
* numa.cell[0-9]*.cache[0-9]*.policy
* numa.cell[0-9]*.cache[0-9]*.size.value
* numa.cell[0-9]*.cache[0-9]*.size.unit
* numa.cell[0-9]*.cache[0-9]*.line.value
* numa.cell[0-9]*.cache[0-9]*.line.unit
This includes support for the following options:
* `emulatorsched.scheduler`
* `emulatorsched.priority`
* `iothreadsched.iothreads`
* `iothreadsched.scheduler`
* `iothreadsched.priority`
This includes support for the following options:
* `shares`
* `period`
* `quota`
* `global_period`
* `global_quota`
* `emulator_period`
* `emulator_quota`
* `iothread_period`
* `iothread_quota`
libvirt 7.2.0 introduced support for a list of firmware features
that should or should not be present. Libvirt takes these into
account when auto-selecting a firmware. Currently supported features
are `enrolled-keys` and `secure-boot`.
This adds support for evdev inputs which were introduced in 7.4.0,
as well as passthrough inputs and some other misc options to complete
the --input command.
New suboptions:
* source.evdev
* source.dev
* source.repeat
* source.grab
* source.grabToggle
* model
This includes support for the following suboptions:
* name (<shmem name=X>)
* role (<shmem role=X>)
* model.type (<shmem><model type=X/>)
* size (<shmem><size>X)
* size.unit (<shmem><size unit=X/>)
* server.path (<shmem><server path=X/>)
* msi.vectors (<shmem><msi vectors=X/>)
* msi.ioeventfd (<shmem><msi ioeventfd=X/>)
There are two domain XML knobs specific to NVDIMMs that
virt-install doesn't allow to set: <pmem/> and <alignsize/>.
Implement them.
Closes: https://github.com/virt-manager/virt-manager/issues/267
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Implement kvm.poll-control.state to `virt-install --feature`. It requires
libvirt >= v6.10.0.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
Implement "<transient shareBacking=yes/>" to virtinst to allow a transient disk
to be shared across VMs. It is introduced to libvirt since:
75871da0ec qemu: Allow <transient> disks with images shared accross
VMs
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
Since libvirt v6.9, the element <transient/> is to configure a disk
which discards its changes while VM was active. Support this element
by cmdline option `--disk ...,transient=on`.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
Support rotation_rate attrib which is introduced since libvirt v7.3.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
xorisso is the still maintained isoinfo alternative, and may be
the only iso reading tool in RHEL9, so we need to support it.
Make it the default for our spec file and test suite too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add support to install a virtual server with passed-through mediated
device. Mediated device can be created using vGPU attached to
vfio_pci driver or DASD attached to vfio_ccw driver or APQNs attached
to vfio_ap driver.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.ibm.com>
This adds the following suboptions to configure <cputune>:
- vcpusched.vcpus
- vcpusched.scheduler
- vcpusched.priority
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Bhyve requires explicit loader configuration. So query
domain capabilities, try to find the "official"
firmware and configure all the necessary loader options.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
For the few bits we are hitting specific code paths, break them
out or fold them into other test cases
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Make use of the new helper for showing a standard error message for two
conflicting cli options. This also catches one untranslatable message.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
If specified, this errors if no OS name was detected or manually set.
So --os-variant detect=on,require=on will error if no OS is detected.
name= can be used as a fallback, so test and document this case
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the following --os-variant suboptions
* name=, short-id=
* id=
* detect=on|off
Functionally this does not change behavior, just adds explicit
sub options for behavior we already support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --os-variant option naming is pretty crappy and mostly a historical
artifact. Ideally this would be named just `--os` but I'm afraid that
would cause confusion with libvirt's <os> XML
Add --osinfo as an alternate commandline naming. If we ever want to
transition documented use of --os-variant it will help to have the
alternative around for a few releases
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --xml option allows users to request raw XML edits to virt-install
or virt-xml generated XML. This gives users a bit of a workaround
incase we don't have proper support for some XML property. The --xml
option can gain more features in the future if it makes sense, like
setting XML namespaces for example.
Basic usage is like: virt-install --xml ./@foo=bar ...
Which will change the generated <domain> XML to have
<domain foo='bar' ...
virt-xml works similarly. It can only be combined with --edit currently.
This only works with xpaths rooted against the entire document.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Similar to behavior we have in virt-manager, if the user destroys the
VM during the VM install process, don't invoke the post install
reboot.
https://bugzilla.redhat.com/show_bug.cgi?id=1818089
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* rename kernelupload.py to volumeupload.py and make the entrypoint
more generic
* move all upload invocation to the Installer class
* use it with cloudinit and unattended ISO generation if required
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a quirk of libvirt that the first <device> is usually a
logical duplicate of the first <serial> device. Adjust virt-xml to
understand this quirk and remove both devices at the same time,
like we already do in virt-manager
https://bugzilla.redhat.com/show_bug.cgi?id=1685541
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This let's us move more of the preserve logic to virtclone.py
and prep more things to share with virt-manager
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Centralize lots of disk building
* Open code virt-clone specific behavior at the source
* Drop a lot or properties
* Move most testing to test_cli.py
* Generally a ton of cleanup
virt-manager clone wizard has not been converted yet so is totally
broken after this commit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cover more cases via the virt-clone CLI testing, than just the
test_cloner.py unit style testing.
Change most of the virt-clone --print-xml testing to also attempt the
clone operation as well via a hidden cli option, to ensure we aren't
testing XML of any bogus operations
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is just a test suite hack from before we had other methods
of specifying cloneable guests. It will be removed soon
We need to tweak some test XML to fix code coverage after
Signed-off-by: Cole Robinson <crobinso@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>
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>
