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 capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to add a similarly-named attribute later, and we'd
like to be consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This test shows what happens when you add a traditional PCI
device such as pci-serial to a pure PCIe machine type such
as aarch64/virt.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Instead of first listing the models on their own, and then
listing them again grouped by the libvirt release they were
introduced in, have a single list.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When preparing for migration, the libxl driver creates a new TCP listen
socket for the incoming migration by calling virNetSocketNewListenTCP,
passing the destination host name. virNetSocketNewListenTCP calls
virSocketAddrParse to check if the host name is a wildcard address, in
which case it avoids adding the AI_ADDRCONFIG flag to the hints passed to
getaddrinfo. If the host name is not an IP address, virSocketAddrParse
reports an error
error : virSocketAddrParseInternal:121 : Cannot parse socket address
'myhost.example.com': Name or service not known
But virNetSocketNewListenTCP succeeds regardless and the overall migration
operation succeeds.
Introduce virSocketAddrParseAny and use it when simply testing if a host
name/addr is parsable.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1557769
Problem with device mapper targets is that there can be several
other devices 'hidden' behind them. For instance, /dev/dm-1 can
consist of /dev/sda, /dev/sdb and /dev/sdc. Therefore, when
setting up devices CGroup and namespaces we have to take this
into account.
This bug was exposed after Linux kernel was fixed. Initially,
kernel used different functions for getting block device in
open() and ioctl(). While CGroup permissions were checked in the
former case, due to a bug in kernel they were not checked in the
latter case. This changed with the upstream commit of
519049afead4f7c3e6446028c41e99fde958cc04 (v4.16-rc5~11^2~4).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This helper fetches dependencies for given device mapper target.
At the same time, we need to provide a dummy log function because
by default libdevmapper prints out error messages to stderr which
we need to suppress.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We store all JSON numbers as strings. To allow using json libraries
that store them in numeric types, use a more predictable and normalized
value.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Rather than using virDomainObjListFindByID, let's be more consistent
and return a reffed and locked object. Since we're using the Ref API,
use virDomainObjEndAPI on @dom and not just virObjectUnlock.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Rather than using virDomainObjListFindByUUID, let's be more consistent
and return a reffed and locked object. Since we're using the Ref API,
use virDomainObjEndAPI on @dom and not just virObjectUnlock.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
For all @dom's fetched from a testDomObjFromDomain because
virDomainObjListRemove will return an unlocked domain object
we should relock it prior to the cleanup label which will use
virDomainObjEndAPI which would Unlock and Unref the passed
object (and we should avoid unlocking an unlocked object).
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Similarly to 3506f1ecfd, the contents of 'cmpcontent' may be an empty
string so the following code would access memory out of the array.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Since RPC support moved out of glibc we need to have explicit deps on
the new packages providing this functionality
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The qemu command line generator code set disk caching of shareable disks
to 'none' when formatting the command line silently. Move this code to a
common place when preparing the domain definition for startup so that it
does not have to be duplicated.
The new test case shows that the actual cache mode will now be recorded
in the live XML definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add a new kind of XML output test for the files in qemuxml2argvtest
where we can validate setup and defaults applied when starting up the
VM.
This is achieved by formatting of the definition processed by the
qemuxml2argvtest into a XML and it's compared against files in
qemuxml2startupxmloutdata. This test is automatically executed if the
output file is present and it's skipped otherwise.
The first example test case is created from 'disk-drive-shared' test
case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The old qcow2 encryption format was buggy, so the new approach is to use
luks inside qcow2. As it turns out, it didn't require that many changes.
It was necessary to fix the command line formatter to stop mangling the
format when secrets are present and specify the encryption format and
secret in correct format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
This format is used by the storage driver and other hypervisors but qemu
does not have notion of the 'iso' format and libvirt does not translate
it to anything useful, so it would not work anyways. Users should use
'raw' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
This is a storage driver type, which is not handled in qemu driver
properly. For accessing directories, disk type 'dir' is used instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
It will be necessary to initialize various aspects for the detected
members of the backing chain. Add a function that will handle it and
call it from qemuDomainPrepareDiskSource and qemuDomainDetermineDiskChain
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
For some reason we've decided to silently translate the disk
detect_zeroes mode if it would be invalid. Extract the
logic so that it does not need to be copypasta'd across the code base.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
In some use cases (mostly in tests) it is not required to check the
seclabel definition validity. Add possibility to call
virDomainDiskDefParse without the domain definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Make the function more usable by returning the full disk definition and
fix the only caller for the new semantics. The new name for the function
is virDomainDiskDefParse.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The function docs state that 'strcontent' may be NULL. This was added in
8b3a0b28ba but that commit neglected to fix rest of the function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
My commit 2e0d6cdec4 claimed qemuMonitorJSONCheckError guarantees
"return" object exists in the JSON reply. But it only makes sure the key
is there, while the type of the value is not checked. A lot of callers
do not care since they only want to see whether their QMP command failed
or not, but any caller which needs to read some data from the reply
wants to make sure the correct data type was returned.
This patch adds a new API called qemuMonitorJSONCheckReply which calls
qemuMonitorJSONCheckError and checks "return" contains a value of the
specified type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Rather than trying to prevent stealing of the 'actions' virJSONValue
into the monitor command replace the code so that it does the same
thing, since 'actions' was actually not really used after calling the
monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Sometimes it's desired to get a JSON number as string. Add a helper.
This will help in cases where we'd want to convert the internal type from
string to something else.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Use virJSONValueObjectGetArray instead of virJSONValueObjectGet so that
it's not necessary to check whether it's an array.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
It was not possible to determine whether virJSONValueObjectAddVArgs and
the functions using it would consume a virJSONValue or not when used
with the 'a' or 'A' modifier depending on when the loop failed.
Fix this by passing in a pointer to the pointer so that it can be
cleared once it's successfully consumed and the callers don't have to
second-guess leaving a chance of leaking or double freeing the value
depending on the ordering.
Fix all callers to pass a double pointer too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Using the 'require' value for the 'policy' attribute indicates
that the guest will have the feature so the host CPU does not
need to support it if the hypervisor can emulate it.
E.g. 'x2apic' is emulated by QEMU even if the host does not support it:
<feature policy='require' name='x2apic'/>
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
qemuDomainDetachWatchdog uses the infrastructure for waiting
for the DEVICE_DELETED event, but the asynchronous delete
was not implemented.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Scan the parsed VMX file, and gather the biggest index of the network
interfaces there: this way, it is possible to parse all the available
network interfaces, instead of just 4 maximum.
Add the VMX file attached to RHBZ#1560917 as testcase esx-in-the-wild-8.
https://bugzilla.redhat.com/show_bug.cgi?id=1560917
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
