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 violates our typical XML hierarchy, but that's how it's modeled
internally in libvirt, and these properties are shared among all
charsource users.
Re-use CharSource, just like libvirt does internally. Adjust all
callers to match. Rename type -> backend_model while we are here,
because type is ambiguous
Move all ./source handling into CharSource, which will be reused by
other device classes as well. This requires us to add ../ handling
into our xmlapi xpath engine
It's not a pattern I think is worth extending in the future, and
make internal refactorings more difficult. Drop it, and drop it
from tpm and char devices since it is now unused
To match the XML schema, rename these subarguments and add aliases
to preserve compatibility:
* driver_queues -> driver.queues
* master -> master.startport
QXL, on the other hand, is still x86-only for some reason.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
libvirt commit 09eb1ae0 added support for a new 'xenbus' controller
type. Add support for the controller in virtinst, including support
for the maxGrantFrames attribute.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
<controller> can have additional <driver> sub element with queues as property,
which is currently not exposed via virt-install. This commit exposes this option
similar to queues in network configuration.
(crobinso: add test case)
This reverts commit a746150bef5298187214dadeb55bdf045bd7a265.
See discussion:
https://www.redhat.com/archives/virt-tools-list/2019-March/msg00058.html
Apparently some debian versions struggle with this. Let's stick with
the old method until there's a sufficiently compelling reason to change
Some adjustment is required to deal with changes added by later patches
Back when this was introduced in 2014 (commit aa772f01e124) using
virtio-scsi instead of virtio-blk made sense, because virtio-pci
support on aarch64/virt was still not widely available and
virtio-mmio couldn't do hotplug.
These days, however, virtio-pci availability is something that
we can assume is present on any remotely reasonable deployment
target, so it's better to no longer behave differently than
other architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We already use virtio-blk for regular disks whenever possible,
and there's no good reason not to do the same with virtio-scsi
when dealing with CDROMs instead of artificially limiting its
use to s390x and ppc64/pseries guests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Instead of duplicating the code into CLI and GUI move it into graphics
device file which is used from both places. This also fixes a bug in
virt-xml where changing listen to address was not working.
This also changes behavior to always configure one listen type when
using CLI listen option or GUI. If user wants to modify only specific
listen type they can use listens[] options from CLI.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1565968
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The convenient 'source' abstraction is not sufficient in all cases,
like is using type=network with a forward mode=bridge network: on
startup, the qemu driver will change the runtime XML to type=bridge
but still list a source network= and bridge= value.
VSOCK sockets allow communication between virtual machines and the host they are
running on.
This patch adds vsock device support along with clitest for the new properties.
Signed-off-by: Slavomir Kaslev <kaslevs@vmware.com>
When creating a new VM and selecting a volume from a network-based
storage pool such as rbd, the volume is not recognized as network-based
and is treated as a volume from a directory storage pool.
This patch adds a method to check if the volume's path points to a
network-based volume, then uses the method to avoid actions like
setting unix file permissions on the volume, which doesn't make
sense for a network-based volume.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
(crobinso: rebase, tweak lookup logic)
This just conceptually makes more sense to keep it all in
one file, and DeviceDisk is the API for the rest of the code
to deal with any host storage state
libvirt will use rtl8139, but the qemu default changed a while
ago to e1000, and libvirt has diverged. e1000 is more modern and
considered the better default here, so use it
