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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The libvirt test driver supports more APIs now, so we are getting
a different error message.
Extend the grep= string to work with both old and new libvirt
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will let us match more complex output, and match error message
differences across libvirt versions
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix the cloud-init config file for --clouduser-ssh key.
Also change ssh_authorized_keys to `ssh_authorized_keys`, and make sure
default user is not deleted when setting ssh key for root.
Fixes commit 22478f307d (virt-install: Add --cloud-init clouduser-ssh-key=)
Resolves: https://github.com/virt-manager/virt-manager/issues/452
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
The test driver was broken for some time and our mdev tests were failing
on most libvirt versions. Recently this was fixed in libvirt 10.4.0 so
skip these tests unless we have new enough libvirt.
This requires extracting some mdev devices from many-devices test case.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This won't make any difference on x86, where either SATA or IDE
is used depending on the machine type, but on other architectures
we want virtio-scsi for a reasonable chance that the guest OS
will recognize the disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Most existing disk images expect UEFI; those that don't, require
either using direct kernel boot or manually providing a firmware
image, both of which imply user intervention.
Using UEFI by default means that at least images belonging to
the first group, of which more are going to pop up as the
ecosystem matures further, can work out of the box.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Cover additional scenarios: direct kernel boot, use of cloud-init,
installation from CDROM and unattended installation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The new capabilities reflect the status of riscv64
virtualization as of Fedora 40, which comes with libvirt
10.1.0 and QEMU 8.2.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
- Add UI coverage
- Drop redundant systray_instance caching
- Tweaks help test and docs
- Show an error if the systray doesn't embed
Signed-off-by: Cole Robinson <crobinso@redhat.com>
- Rework the ConsolePages abstraction to carry the Gtk.Menu. makes
it all less messy
- Make the console menu the single source of truth for console
embeddability, and error message reporting
- Small misc cleanups here and there
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Not quite sure what's going on here, I think it has something to
do with slowness when the accessibility bus is being polled.
Add some infrastructure to increase the timeout while we wait for
the app to pop up
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Newer libvirt + edk2 will default to nvram in qcow2 format, but
our domain rename code had some .fd assumptions baked in.
Adjust uitests to handle it too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
I have no idea if the generated config is optimal, but this
at least provides a base for us to confirm when defaults change.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The libvirt test driver now has implementations for hotplug routines,
which broke string matching for one case.
Loosen it up to work for old and new libvirt versions.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When specifying the socket.source option for filesystem devices, like
this:
--filesystem type=mount,driver.type=virtiofs,source.socket=/xyz.sock,target.dir=tag1
virt-install is writing the xml as:
<filesystem type="mount">
<source>
<socket>/xyz.sock</socket>
</source>
<target dir="tag1"/>
<driver type="virtiofs"/>
</filesystem>
This produces an error such as:
ERROR missing source information for device mount_tag1
But the socket should be an attribute of source rather than a child
element. After this patch, the same command results in the following XML
and no error is produced:
<filesystem type="mount">
<source socket="/xyz.sock"/>
<target dir="tag1"/>
<driver type="virtiofs"/>
</filesystem>
Resolves: RHEL-1126
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Nowadays with libvirt split daemons, libvirtd isn't required to
be installed for a first run local connection to succeed, so we
are needlessly blocking the app from 'just working' in many cases.
Especially considering that many distros often have libvirt running
out of the box due to gnome-boxes pulling it in.
Drop the daemon checking entirely.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When shim in the guest sees unpopulated EFI NVRAM, like when
we create a new UEFI VM, it invokes fallback.efi to populate
initial NVRAM boot entries. When the guest also has a TPM device,
shim will do a one time VM reset. This reset throws off the
reboot detection that is central to virt-install's install
process.
The main install case that this will usually be relevant is
the combo of UEFI and --cloud-init. The latter usually implies
use of a distro cloud image, which will be using shim, and the
--cloud-init process requires a multi stage install compared
to just a plain import install.
For that case, we disable the default TPM device for the first
boot.
https://bugzilla.redhat.com/show_bug.cgi?id=2133525
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libosinfo seems to generate Fedora tree URLs using the "https", not
"http", scheme now; which breaks CI. Update the expected outputs
accordingly.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
virt-install prints the total_size value to the progress bar even if it
is meaningless.
This value can be confusing to user, so for execute prosess that doesn't
copy files (total_size = 0B), we hide the total_size value.
For example, 'Creating domain...' doesn't need to print the total_size
value.
Signed-off-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
Signed-off-by: Haruka Ohata <ohata.haruka@fujitsu.com>
Reproducer:
Reproducer:
./virt-install --connect test:///default \
--location tests/data/fakemedia/fake-f26-netinst.iso
Before:
Starting install...
Retrieving 'vmlinuz' | 0 B 00:00:00 ...
Retrieving 'initrd.img' | 0 B 00:00:00 ...
After:
Starting install...
Retrieving 'vmlinuz' | 9 B 00:00:00 ...
Retrieving 'initrd.img' | 9 B 00:00:00 ...
progress.end() currently only reports the total amount of bytes
that were last written to the UI. It should report the total amount
that's been passed to update().
Reported-by: Toshiki Sonoda <sonoda.toshiki@fujitsu.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The sheepdog project is no longer actively developed, Libvirt removed
the support for sheepdog storage backend since v8.8.0, Let's drop it.
Signed-off-by: Lin Ma <lma@suse.com>
This commit added support for cpu physical address bits control, It's
useful for VMs with huge amount of ram.
E.g.
--cpu Cascadelake-Server,maxphysaddr.mode=emulate,maxphysaddr.bits=46
Signed-off-by: Lin Ma <lma@suse.com>
Anything passed to --boot should imply --install no_install=yes
in the absence of other --install options. This is historically
what we've done but we regressed in 4.1.0
Resolves: https://github.com/virt-manager/virt-manager/issues/426
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Each bit here is part of the CLI API, we need to be sure we are
covering each one. Extend the test suite to hit one case we are missing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Properly setting the metadata cache size can provide better performance
in case of using big qcow2 images.
This patch introduces two driver options:
* driver.metadata_cache.max_size
* driver.metadata_cache.max_size.unit
E.g. --disk ...,driver.type=qcow2,\
driver.metadata_cache.max_size=2,\
driver.metadata_cache.max_size.unit=MiB
BTW, Metadata cache size control is currently supported only for qcow2.
Regarding how to properly caluclate the cache size of qcow2, Please refer
to qemu's documentation.
Signed-off-by: Lin Ma <lma@suse.com>
We need to change the flow from
* parse all the strings
* set capabilities defaults
* build installer
* fill in all guest defaults
To
* parse boot and metadata strings
* set capabilities defaults
* build installer
* set --name default
* parse all the remaining strings
* fill in all guest defaults
Because --disk parsing depends on --name for some path generation.
So this fixes --disk names when --name is implicitly specified by
--install or --osinfo
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The diff_compare rstrip() should never have been added, let's fix
it once and for all but dealing with missing newlines in the diff
helper
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It allows to set the thread pool size to optimize spawning worker threads
for the default event loop in real time environment. For example:
--iothreads defaultiothread.thread_pool_min=8,\
defaultiothread.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
These two optional attributes allow setting lower and upper boundary for
number of worker threads for given IOThread. For example:
--iothreads iothreads=2,\
iothreadids.iothread0.id=1,\
iothreadids.iothread1.id=2,\
iothreadids.iothread1.thread_pool_min=8,\
iothreadids.iothread1.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
This allows support for host/guest clipboard sharing when using vnc
guests (and possibly other graphics types in the future). This channel
is similar to the spicevmc channel, but it contains a couple additional
options to enable/disable clipboard sharing and specify the mouse mode.
In the case of spice, these settings are specified on the 'graphics'
element, but for qemu-vdagent, they are specified on the channel. For
example:
--channel=qemu-vdagent,source.clipboard.copypaste=on,source.mouse.mode=client
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Originally we thought it would be for the clouduser, but then
we changed it, and now it's ambiguous. Rename it to make the
usage clear, and add an alias to keep any users working
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The Guest object passed in by the user is no longer altered in place,
instead we act on copies of the original XML. We need to rework how
unattended/cloudinit device altering works a bit to handle this.
There's some XML churn because working on parsexml gives different
output ordering, but this is expected.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* libvirt fills in cbitpos and reducedPhysBits for us
* libvirt errors if type is missing
* libvirt errors if host/qemu doesn't support sev
So drop it all. This simplifies testing because we don't need
sev domcaps in place just to generate the XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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>
This reverts commit 20d3bf9484.
Indeed graphics does work on aarch64, but for example, fedora
server aarch64 installs don't output any graphical output and only
put data on the serial console. So we would need to be more specific
about how we enable this if we make the change.
qemu 6.1, fairly new when we added this option, has an unfortunate
bug with >= 15 root ports, so we choose 14 instead of our original 16
https://gitlab.com/qemu-project/qemu/-/issues/641
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>
If the user selects virtiofs when editting or adding a new VM, and
we don't detect that they have shared memory enabled, show
a warning label in the UI pointing them to the Memory screen.
It would be nicer if we did this for them, but to get that totally
correct would require both duplicating libvirt's shared memory
detection logic, and some surgery to the addhw wizard. This is good
enough for now
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>
Split out tpmdetails.py, following the pattern of fsdetails.py. This
adds more UI editing fields for an already attached TPM.
Move the model and version under an 'Advanced options' expander,
since we should be getting this correct by default.
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>
Adjust the UI to leave the box checked for both host-model and
host-passthrough, but host-passthrough is now what it means when
the user selects it. host-model can still be selected via the
CPU model drop down list
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When libvirt and qemu are new enough, use host-passthrough for the
CPU default. Nowadays this is recommended over host-model for most
end user usage where migration isn't a critical feature.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
These have been used in the past, but no current code touches them,
so drop the parsing infrastructure
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>
Historically over time it's been more likely that an issue is reported
for osinfo-db missing the usb-tablet annotation. So for example we
always enable it for the default 'generic' case. We also want to
enable it for osinfo's 'unknown' case too.
Rather than add another check for that, let's just drop the osinfo
checking entirely. Some very old OS don't support usb-tablet, but
specifying it for those cases doesn't cause issues AFAIK, and users
can override it with `--input none` if they want.
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>
- Move tooltip to the tree row instead of the finish button
- Some style cleanups
- Add a hack so we can hit it in the test suite
Signed-off-by: Cole Robinson <crobinso@redhat.com>
After checking with qemu devs, this option is not really recommended
for common usage and doesn't get used much in practice. So I don't
think it is suitable for the UI
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>
This is from Gerd's suggestions here:
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
When the guest supports it, we should use virtio. qxl is on the way
out, and the benefits are marginal and add a security and maintenance
burden.
While here, check domcaps that qxl or virtio are actually available.
Modern qemu has device modules, so device support may not be installed.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Make it clear in code and UI that this is x86 only. Other arches
either require UEFI (aarch64) or don't support it
* Drop the internal 'bios' values since we don't handle them and may
not want them anyways, since when win11 support lands we will need
to explicitly throw an error if the user tries to force bios
* Add UI tests
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Let users choose libvirt's os.firmware=efi setting in the UI, putting
it about the firmware path list, since it's the preferred default
these days.
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>
I removed Portgroup UI in 4c3c53f773 release 3.0.0, but there's been
a steady stream of requests to bring it back. It seems it's commonly
used with some certain openvswitch config.
Maint burden isn't too bad. Let's bring it back
Fixes: https://github.com/virt-manager/virt-manager/issues/169
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>
