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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts b34ae0d0c8 and
1fef5d8661.
Playing with this some more I found some deeper problems. For example
```console
[:~/src/virt-manager] (main) $ ./virt-xml test-for-virtxml --connect test://`pwd`/tests/data/testdriver/testsuite.xml --print-diff --edit 1 --video model=FOO --edit 2 --sound model=BAR
--- Original XML
+++ Altered XML
@@ -180,14 +180,14 @@
<graphics type="vnc" port="-1" autoport="yes">
<listen type="address"/>
</graphics>
- <sound model="sb16"/>
+ <sound model="BAR"/>
<sound model="es1370"/>
<sound model="ich6"/>
<video>
<model type="vmvga" vram="16384" heads="1" primary="yes"/>
</video>
<video>
- <model type="cirrus" vram="16384" heads="3"/>
+ <model type="FOO" vram="16384" heads="3"/>
</video>
<hostdev mode="subsystem" type="usb" managed="yes">
<source>
```
There's other weirdness too, though it's mostly strange plays on previous weird behavior
* `--edit --video model=vga --edit --sound model=ich9 --video model=qxl` works
* `--add-device --sound model=foo --video model=bar` was previously rejected but now works
* `--remove-device --video model=vmvga --sound model=sb16` was previously rejected by now works
Fixing all this is not trivial. So I think we need to revert and go back to the drawing board.
This makes it easier for users to change video model from QXL to
different model as QXL is special and uses other attributes that are not
supported by any other model. Without this code libvirt would report
error or user would have to request `clearxml`.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
When Spice graphics is used QEMU creates a Spice server and communicates
with Spice client using multiple channels. These channels are used by
the spice devices as well. Without the Spice graphics defined there is
no use for the other devices. In addition libvirt will report error for
such configuration.
Signed-off-by: Pavel Hrdina <phrdina@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>
conn.fetch_all_vols() is slow, taking ~0.03s every time it's used. When
handling with a large number of paths, its performance is too bad and
could stuck UI for a very long time.
DeviceDisk.paths_in_use_by is added to help handle many paths with
only one call to conn.fetch_all_vols().
Add adaptations for loongarch with the following features:
Default video Support
UEFI prefer
Usb tablet and usb keyboard
rng and memballoon
sound device
Usb controller
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
While the shorthand saves a tiny bit of typing, it is confusing
to people coming from QEMU, where -cpu host is the equivalent
of our --cpu host-passthrough. It's better to stick with the
unambiguous names used by libvirt.
Besides, the GUI already uses "host-model" throughout, so
advocating its use in the CLI too increases the internal
consistency.
https://issues.redhat.com/browse/RHEL-40003
Signed-off-by: Andrea Bolognani <abologna@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>
With libvirt 9.8.0, the test driver now has a stub getDomainCapabilities
implementation. But we still have some code that needs to handle
a driver with missing domcaps.
Make our magicuri mock return NO_SUPPORT for domcaps, when the URI
doesn't have any domcaps XML passed in. This is enough for our test
purposes.
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>
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>
Commit f107e39989 ("Switch to more traditional logging structure",
2019-06-17) replaced "logging.exception" with "log.exception", effectively
shifting the argument lists 4 characters to the left. The second and
further lines of multiline invocations were not accordingly unindented,
however, which ended up setting a suboptimal precedent as well. Unindent
those lines now.
Reported-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Just to be sure, this patch implements the second approach (described in
the previous patch) as well.
Note that there is precedent for suppressing "guest_lookup" exceptions:
refer to the "Error determining machine list" branch from commit
ae7ebc220b ("details: Properly limit machine type list by guests
arch/type", 2013-09-01).
(
In fact, that branch gets activated when opening the details window for a
domain that uses a non-default emulator; the "virt-manager --debug" log
contains:
> ERROR (details:613) Error determining machine list
> Traceback (most recent call last):
> File "virtManager/details/details.py", line 605, in _init_details
> capsinfo = caps.guest_lookup(
> File "virtinst/capabilities.py", line 319, in guest_lookup
> raise ValueError(msg)
> ValueError: Host does not support domain type kvm with machine
> 'pc-q35-8.1' for virtualization type 'hvm' with architecture 'x86_64'
)
Fixes: #539
Fixes: 05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
When I try to open the details window for a domain that does not use the
system default emulator, I get the following exception:
> Traceback (most recent call last):
> File "virtManager/vmwindow.py", line 40, in get_instance
> cls._instances[key] = vmmVMWindow(vm)
> File "virtManager/vmwindow.py", line 83, in __init__
> self._details = vmmDetails(self.vm, self.builder, self.topwin,
> File "virtManager/details/details.py", line 389, in __init__
> self._init_details()
> File "virtManager/details/details.py", line 807, in _init_details
> vmmAddHardware.build_video_combo(self.vm, video_dev)
> File "virtManager/addhardware.py", line 816, in build_video_combo
> default = DeviceVideo.default_model(vm.xmlobj)
> File "virtinst/devices/video.py", line 47, in default_model
> if (guest.lookup_domcaps().supports_video_virtio() and
> File "virtinst/guest.py", line 656, in lookup_domcaps
> if not self._domcaps or not _compare(self._domcaps):
> File "virtinst/guest.py", line 646, in _compare
> if self.os.machine and not _compare_machine(domcaps):
> File "virtinst/guest.py", line 633, in _compare_machine
> capsinfo = self.lookup_capsinfo()
> File "virtinst/guest.py", line 674, in lookup_capsinfo
> self._capsinfo = self.conn.caps.guest_lookup(
> File "virtinst/capabilities.py", line 319, in guest_lookup
> raise ValueError(msg)
> ValueError: Host does not support domain type kvm with machine
> 'pc-q35-8.1' for virtualization type 'hvm' with architecture 'x86_64'
This is a regression; according to git-bisect, it was introduced in commit
05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27).
"lookup_capsinfo" (and "guest_lookup" called by it) are unsuitable for
machine type alias checking (or for anything else) if the domain uses an
emulator that differs from the system default emulator. The information
returned by virConnectGetCapabilities() pertains to the system default
emulator. Thus, when using a non-default emulator, we should either not
call "lookup_capsinfo" for machine type alias checking, *or* we should
suppress the exception, and pretend that the alias check was a mismatch.
It turns out that we can avoid the "lookup_capsinfo" call (and thereby the
exception) in practice if we just delay the call until after the direct
(non-alias) comparison.
Fixes: #539
Fixes: 05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Before this, on clone the serial file would remain the same for the cloned
domain. This doesn't make much sense as the output would be an intermix of two
unrelated output sequences.
Here we apply the the same filename changing algorithm, as with disk files.
Signed-off-by: Oleg Vasilev <oleg.vasilev@virtuozzo.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>
When a sparse file is created during a disk allocation,
virt-install prints not the created disk size but a sparse file size.
Therefore, we fix to print the created disk size during disk allocation
instead of the size of the sparse file by updating the meter with the
self.capacity.
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>
Nowadays it could be as simple as `virt-install --install fedora36`.
Trying to represent the interdepencies here is not worth it, but
let's keep a simple string around to avoid the default parser
usage string, which is huge
Signed-off-by: Cole Robinson <crobinso@redhat.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>
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>
Otherwise going host-passthrough -> custom can cause libvirt validation
error due to libvirt fills the default value(migratable='on') for the
host-passthrough in domain XML.
Signed-off-by: Lin Ma <lma@suse.com>
Remove the open coded version logging in cli.py and virt-manager
connection.py, and move it into virtinst connection open
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The various version numbers reported by libvirt are all relevant pieces
of information when debugging problem reports.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Knowledge of the version number is not always available from the user
bug report. They may merely have a log file from an automated system.
Including the version number in the log message is key information.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The domain capabilities XML always contains the canonical machine name.
When the selected machine type for a guest is an alias, the check
comparing it to the domain capabilities machine will always fail. This
prevents the domain capabilities result from being cached.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.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>
Since there's a release pending, this is a bit of future proofing
if win11 pops up in a future osinfo-db without accompanying
libosinfo firmware APIs landing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Check it for test:/// URI too
* Move the whole logic into osdict.requires_firmware_efi
* Wrap it all in an exception handler the final API breaks us
* Add some coverage exclusions since this is currently untestable
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Windows 11 only supports EFI for installation, legacy BIOS is
discontinued as an option for new installs, unless you switch into
the console and run various regedit hacks in the installer.
This is not something we expect users to do, so osinfo-db will
report:
<firmware arch="x86_64" type="efi"/>
<firmware arch="x86_64" type="bios" supported="false"/>
for Windows 11.
When seeing 'bios' with supported=false, we need to prefer EFI
firmware no matter what.
For other OS we should stil prefer BIOS, because EFI blocks the usage of
internal qcow2 snapshots until some libvirt work is done to use the new
QMP snapshot commands.
Note this relies on a new API osinfo_os_get_complete_firmware_list
just added to libosinfo in version 1.10, so for most existing OS
distros this will be dormant functionality until they rebase to
latest libosinfo APIs.
The Windows 11 entry for osinfo-db will be the first that exposes
the metadata indicating lack of BIOS support.
Related: https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
`sudo` throws errors and is not even required to write the `disable`
file. Also add a message to the file that it was created by us
Signed-off-by: Cole Robinson <crobinso@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>
