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 reason we fork by default, is to force ssh to invoke
ssh-askpass when a password is required, rather than prompt on
a terminal no one is looking at. There's a more thorough
explanation here:
https://github.com/virt-manager/virt-manager/issues/731
With SSH_ASKPASS_REQUIRE=force, we now have a way to force ssh
to use askpass in the above scenario, when ssh and libvirt are new
enough.
The default forking behavior has caused maintenance pain in the
past, and is currently causing issues on macos:
https://github.com/virt-manager/virt-manager/issues/620
Let's flip the default to `--no-fork`. The VIRT_MANAGER_DEFAULT_FORK
env variable is there as an escape hatch incase I really miscalculated.
I don't expect many people are depending on use of askpass either
way, or if they are, they are launching virt-manager from their
desktop and not a terminal, which already gives us the correct
behavior AFAICT>
My suspicion is barely anyone will notice, which is why
I'm ok with changing this now, despite the libvirt support being
brand new.
If this doesn't raise any issues, then we can eventually drop
the forking behavior all together.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a special convenience option for filling in `type=hostdev`
config using the same format of lookup string that can be
passed to `--hostdev`
Fixes: https://github.com/virt-manager/virt-manager/issues/500
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix no longer valid URL fragments, wrap at 80th column, remove dots that
follow only a few links.
Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
This wires up the guest.convert_to_vnc function to command line,
and documents it.
There's one suboption `qemu-vdagent=on|off`, defaulting to `off`
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Wire up guest.convert_to_q35 to the CLI. We add one suboptions,
`num_pcie_root_ports=X`, matching the pre-existing
`--controller num_pcie_root_ports=X` option
Nothing fancy here. See man page docs for details
Signed-off-by: Cole Robinson <crobinso@redhat.com>
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.
- 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>
It is common on x86 and other architectures to install a guest from
network by using "--boot hd,network" with virt-install - as long as
the hard disk is not bootable yet, the installation will be started
via network, and once it finished, the guest can boot from hd during
the next reboot.
However, this does not work on s390x since this architecture only
supports one single boot device to be passed to the guest. Thus add
a note to the documentation to avoid that people are running again
into this common pitfall.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2032472
Signed-off-by: Thomas Huth <thuth@redhat.com>
Provide ready to use recipes for explicitly enabling and
explicitly disabling Secure Boot, as well as a pointer to
the more extensive information found on the libvirt website.
Setting loader_secure=yes is only one part of a proper Secure
Boot setup, so stop documenting it in the section about manual
firmware selection to avoid confusion.
https://bugzilla.redhat.com/show_bug.cgi?id=2112154https://bugzilla.redhat.com/show_bug.cgi?id=2149971
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Firmware autoselection is the way to go in most cases, so
recommend that instead of telling users that they should provide
all information manually.
Signed-off-by: Andrea Bolognani <abologna@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>
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>
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>
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>
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>
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>
https:// needs to link to the exact site, not the debian.org redirect,
otherwise we get browser cert warnings
Fixes: #360
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit 85307b9bd2 changed the default
value for 'accessmode' from 'passthrough' to 'mapped', but forgot to
update the documentation in the man page.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
In real world silicon though it is rare to have high socket/die counts,
but common to have huge core counts.
Some OS will even refuse to use sockets over a certain count.
Thus we prefer to expose cores to the guest rather than sockets as the
default for missing fields.
This matches a recent change made in QEMU for new machine types
commit 4a0af2930a4e4f64ce551152fdb4b9e7be106408
Author: Yanan Wang <wangyanan55@huawei.com>
Date: Wed Sep 29 10:58:09 2021 +0800
machine: Prefer cores over sockets in smp parsing since 6.2
Closes: https://github.com/virt-manager/virt-manager/issues/155
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>
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/>)
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>
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>
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>
Support the io_uring io mode, introduced since Libvirt v6.3.0.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
The builtin rng backend uses getrandom syscall to generate random, no
external rng source needed, introduced from libvirt v6.1.0.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
