In other tests we use "expected" and "actual" to refer to the expected
outcome of the tested API and the result we got, respectively.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Add the data structure and infrastructure to support an initialization
vector (IV) secrets. The IV secret generation will need to have access
to the domain private master key, so let's make sure the prepare disk
and hostdev functions can accept that now.
Anywhere that needs to make a decision over which secret type to use
in order to fill in or use the IV secret has a switch added.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Create helper API's in order to build the network URI as shortly we will
be adding a new SecretInfo type
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than need to call qemuDomainSecretDestroy after any call to
qemuProcessLaunch, let's do the destroy in qemuProcessLaunch since
that's where command line is eventually generated and processed. Once
it's generated, we can clear out the secrets.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Commit id '40d8e2ba3' added the function to qemuProcessStart because
in order to set up some secrets in the future we will need the master
key. However, since the previous patch split the master key creation
into two parts (create just the key and create the file), we can now
call qemuDomainSecretPrepare from qemuProcessPrepareDomain since the
file is not necessary.
Signed-off-by: John Ferlan <jferlan@redhat.com>
A recent review of related changes noted that we should split the creation
(or generation) of the master key into the qemuProcessPrepareDomain and leave
the writing of the master key for qemuProcessPrepareHost.
Made the adjustment and modified some comments to functions that have
changed calling parameters, but didn't change the intro doc.
Signed-off-by: John Ferlan <jferlan@redhat.com>
From a review after push, add the "_TYPE" into the name.
Also use qemuDomainSecretInfoType in the struct rather than int
with the comment field containing the struct name
Signed-off-by: John Ferlan <jferlan@redhat.com>
This removes the opencoded payload freeing in the client, to use
the shared virNetMessageClearPayload call. Two changes:
- ClearPayload sets nfds=0, which fixes a potential crash if
an error path called virNetMessageFree/Clear on the message
after fds was free'd
- We drop the inner loop VIR_FORCE_CLOSE... this may mean fds are
kept open a little bit longer if the call is blocking but in
practice I don't think it will have any effect
I've noticed this while trying to compile libvirt on my arm box.
CC rpc/libvirt_net_rpc_server_la-virnetserverclient.lo
rpc/virnetserverclient.c: In function 'virNetServerClientNewPostExecRestart':
rpc/virnetserverclient.c:516:45: error: cast increases required alignment of target type [-Werror=cast-align]
(long long *) ×tamp) < 0) {
^
cc1: all warnings being treated as errors
Problem is, @timestap is defined as time_t which is 32 bits long,
and we are typecasting it to long long which is 64bits long.
Solution is to make @timestamp type of long long. At the same
time, we can make @conn_time in _virNetServerClient struct long
long too. There is no need for it to be type of time_t.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In this function, @id is defined as unsigned long long. When
passing this variable to virJSONValueObjectGetNumberUlong(),
well address of this variable, it's typecasted to ull*. There
is no need for that. It's a same story with @nrequests_max.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Adding new *.replies files for qemucapabilitiestest or updating the
files when libvirt adds an additional QMP command into the probing
process is quite painful. The goal of the new qemucapsprobe command is
to make this process as easy as
tests/qemucapsprobe /path/to/qemu/binary >caps.replies
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
json_reformat uses two spaces for when indenting nested objects, let's
do the same. The result of virJSONValueToString will be exactly the same
as json_reformat would produce.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virQEMUCapsNewForBinary unconditionally loads data from cache and probes
using both QMP and -help parsing, which is suboptimal when we want to
use it in tests.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The new VIRT_TEST_PRELOAD macro does not force the caller to create a
special main function which would need to be called through
virtTestMain().
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Currently all qemu driver tests are statically linked to qemu driver
library, which makes it impossible to mock any API from the library.
This patch creates a shared qemu driver library which can be used
instead of the static one.
NB we can't use libvirt_driver_qemu.so directly since it is linked with
-module and it is supposed to be dlopened.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Bhyve supports ACPI shutdown by issuing SIGTERM signal to a bhyve
process.
Add the bhyveDomainShutdown() function and virBhyveProcessShutdown()
helper function that just sends SIGTERM to VM's bhyve process. If
a guest supports ACPI shutdown then process will be terminated and
this event will be noticed by the bhyve monitor code that will handle
setting proper status and clean up VM's resources by calling
virBhyveProcessStop().
Current implementation of domainDestroy for bhyve calls
virProcessKillPainfully() for the bhyve process and then
executes "bhyvectl --destroy".
This is wrong for two reasons:
* bhyvectl --destroy alone is sufficient because it terminates
the process
* virProcessKillPainfully() first sends SIGTERM and after few
attempts sends SIGKILL. As SIGTERM triggers ACPI shutdown that
we're not interested in, it creates an unwanted side effect in
domainDestroy.
Also, destroy monitor only after "bhyvectl --destroy" command succeeded
to avoid a case when the command fails and domain remains running, but
not being monitored anymore.
We can't guarantee which 64-bit type will be used in an RPC struct;
while %lu worked on 64-bit Linux, that won't always be the type
used on all 64-bit platforms; and certainly is not right for 32-bit:
admin.c: In function 'adminDispatchClientGetInfo':
admin.c:265:25: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'uint64_t {aka long long unsigned int}' [-Werror=format=]
Signed-off-by: Eric Blake <eblake@redhat.com>
cmdDetachInterface function checks for live config
flags and then passes the live/config domain xml
to virshDomainDetachInterface accordingly.
Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
Since nparams can be technically negative, it is a good practice throughout
our code to check if nparams actually has a non-negative value. The same effect
would be achieved by converting our internal typed params serializer argument
to 'unsigned' type, but it definitely would not be the path of least resistance.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
When virHostValidateCPUFlag returns NULL, that's more an unexpected
error than the sign of missing CPU flags. Let's react to this
appropriately.
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1286709
Now that we have all the pieces in place, we can add the 'iothread=#' to
the command line for the (two) controllers that support it (virtio-scsi-pci
and virtio-scsi-ccw). Add the tests as well...
Rather than an if statement, use a switch.
The switch will also catch the illegal usage of 'iothread' with some other
kind of unsupported bus configuration.
Add the ability to add an 'iothread' to the controller which will be how
virtio-scsi-pci and virtio-scsi-ccw iothreads have been implemented in qemu.
Describe the new functionality and add tests to parse/validate that the
new attribute can be added.
Previous commit moved some lists out of the -devel package
and into the -docs package
commit feffcc03a0
Author: Cole Robinson <crobinso@redhat.com>
Date: Wed Apr 13 10:37:42 2016 -0400
spec: Only pull in API docs with -devel package
What was not realized is that the rule 'libvirt-docs/*'
and ' docs/*.html docs/html docs/*.gif' actually point
to the exact same content. ie, we had previously included
the website HTML in *both* the -docs and -devel packages.
So this change ended up listing the files twice, which
caused RPM to print a load of warnings:
warning: File listed twice: /usr/share/doc/libvirt-docs/html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/32favicon.png
warning: File listed twice: /usr/share/doc/libvirt-docs/html/404.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/acl.html
warning: File listed twice: /usr/share/doc/libvirt-docs/html/aclpolkit.html
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Commits 52a2eef9 and 62be5486 forgot to add these errors to daemon's error
whitelist, i.e. in order to avoid log file pollution with errors like "Domain
not found" or "Server not found" in this case, since these events are valid
and expected to occur.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Rather than be specific about which devices in the <iothreads> description,
let's leave that for the <disk> description for it's <iothread> value.
Signed-off-by: John Ferlan <jferlan@redhat.com>
An iothread for virtio-scsi is a property of the controller. Add a lookup
of the 'virtio-scsi-pci' and 'virtio-scsi-ccw' device properties and parse
the output. For both, support for the iothread was added in qemu 2.4
while support for virtio-scsi in general was added in qemu 1.4.
Modify the various mock capabilities replies (by hand) to reflect the
when virtio-scsi was supported and then specifically when the iothread
property was added. For versions prior to 1.4, use the no device error
return for virtio-scsi. For versions 1.4 to before 2.4, add some data
for virtio-scsi-pci even though it isn't complete we're not looking for
anything specific there anyway. For 2.4 to 2.6, add a more complete reply.
Signed-off-by: John Ferlan <jferlan@redhat.com>