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>
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>
This was raised here:
https://www.redhat.com/archives/virt-tools-list/2019-June/msg00117.html
Quoting from that:
"""
virt-convert takes an ovf/ova or vmx file and spits
out libvirt XML. It started as a code drop a long time ago that could
translate back and forth between vmx, ovf, and virt-image, a long dead
appliance format. In 2014 I converted it to do vmx -> libvirt and ovf ->
libvirt which was a CLI breaking change, but I never heard a peep of a
complaint. It doesn't seem to do a particularly thorough job at its
intended goal, I've seen 2-3 bug reports in the past 5 years and
generally it doesn't seem to have any users. Let's kill it. If anyone
has the desire to keep it alive it could live as a separate project
that's a wrapper around virt-install but there's no compelling reason to
keep it in virt-manager.git IMO
"""
Nothing has changed since then, so here is the removal.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Stop listing sub options, since there's multiple, and most won't
need to be specified.
* Give an example for type=emulator
Reported-by: Junqin Zhou <juzhou@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When running virt-install as root, user-login would be automatically set
to "root", causing an installation failure in the most part of the
distros (if not all of them).
In order to avoid such failures, let's raise a runtime error in case the
user-login used is "root".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's allow setting the login of the guest user.
Using the user from the system is a quite good fallback, but would break
unattended installations when running virt-install as root. Thus, for
those cases, it makes sense to have the option of setting the user
login.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's not expose the user/root password in the CLI and, instead, let's
rely on a file passed by the admin and read the password from there.
'CVE-2019-10183' has been assigned to the virt-install --unattended
admin-password=xxx disclosure issue.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
* Renaming HACKING.md to CONTRIBUTING.md, special github naming
* Point to modern virt-manager.org bug link
* Mention option to use github issue tracker
* Point to the github wiki for more contribution docs
* Many minor updates
The <domain> XML it alters is called <seclabel>, and security is
really generic sounding. Add the alias and switch the documentation
over to prefer --seclabel
There is a new security feature 'md-clear' that mitigates recent CPU
Microarchitectural Store Buffer Data vulnerability.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* backend_connect_host -> backend.source.connect_host
* backend_connect_service -> backend.source.connect_service
* backend_host -> backend.source.host
* backend_mode -> backend.source.mode
* backend_service -> backend.source.service
* backend_type -> backend.type
* rate_bytes -> rate.bytes
* rate_period -> rate.period
'type', and 'device' are kept as advertised options,
due to them being commonly specified and documented
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* protocol -> protocol.type
* target_address -> target.address
* name -> target.name
* target_type -> target.type
'host', 'path', 'mode', and 'bind_host' are kept as advertised options,
due to them being commonly specified and documented
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* cid -> cid.address
* auto_cid -> cid.auto
Add man docs for --vsock while we are at it, since they are missing
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* driver_queues -> driver.queues
* master -> master.startport
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* suspend_to_disk -> suspend_to_disk.enabled
* suspend_to_mem -> suspend_to_mem.enabled
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* cell[0-9]*.cpus -> numa.cell[0-9]*.cpus
* cell[0-9]*.distances.sibling[0-9]*.id -> numa.cell[0-9]*.distances.sibling[0-9]*.id
* cell[0-9]*.distances.sibling[0-9]*.value -> numa.cell[0-9]*.distances.sibling[0-9]*.value
* cell[0-9]*.id -> numa.cell[0-9]*.id
* cell[0-9]*.memory -> numa.cell[0-9]*.memory
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
- device_path -> device.path
- device_weight -> device.weight
We shouldn't be duplicating libvirt documentation here. If someone
needs <virtualport> config, they are likely working backwards from
working XML and trying to figure out the command line. Drop most
of the details
Petr Benes