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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 a746150bef.
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 aa772f01e1) 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
I know openstack uses tcp consoles but for end users I've never
really heard about it. RHEL compiles out udp as well. I'm fine telling
users to go to the cli and use virt-xml for this use case.
Use this opportunity to drop a lot of code that only simplified the
case when there are tons of char options we need to consider
An emulated backend doesn't require any path, since libvirt will take
care of finding the emulator and managing the storage. However, the
version to emulate can be specified.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There is only one for now, but we are adding CRB next (and SPAPR is
being added too in qemu/libvirt).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Add codec support to virt-install so that it can accommodate
multiple instances of codec configuration.
The commandline argument:
--sound codec0.type=micro,codec1.type=duplex,codec2.type=output
maps to the sound XML below:
<sound model="es1370">
<codec type="micro"/>
<codec type="duplex"/>
<codec type="output"/>
</sound>
Signed-off-by: Anya Harter <aharter@redhat.com>
The copyright headers in every file were chjanged in this previous commit
commit b6dcee8eb7
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 20 15:00:02 2018 -0400
Use consistent and minimal license header for every file
Where before this they said "
"either version 2 of the License, or (at your option) any later version."
Now they just say
"GNU GPLv2"
This fixes it to say "GNU GPLv2 or later" again.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The way we enumerate devices doesn't conform with the way all
other XMLBuilder instances expose child objects. Move more towards
that direction.
This requires some virt-xml and cli.py hacks but we will remove those
in future patches
