To allow encryption of the non-shared storage migration NBD connection
we will need to instantiated the NBD server with the TLS env.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The s390 testcase verifies that the s390-specific cpu-state
field is correctly mapped to the halted property.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Extended the json monitor test program with support for query-cpus-fast
and added a sample file set for x86 data obtained using the it.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use query-cpus-fast instead of query-cpus if supported by QEMU.
Based on the QEMU_CAPS_QUERY_CPUS_FAST capability.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Print out the halted property in the test output.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since the monitor code no longer needs to see this enum, we move it
to the place where migration parameters are defined and drop the
"monitor" reference from the name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to have all migration capabilities parsing and formatting at one
place, i.e., in qemu_migration_params.c. The parsing is already there in
qemuMigrationCapsCheck.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The test is mostly useless and we want to refactor migration parameters
even further. The refactoring will allow us to introduce enhanced tests
for migration parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally QEMU provided query-migrate-cache-size and
migrate-set-cache-size QMP commands for querying/setting XBZRLE cache
size. In version 2.11 QEMU added support for XBZRLE cache size to the
general migration paramaters commands.
This patch adds support for this parameter to libvirt to make sure it is
properly restored to its original value after a failed or aborted
migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rework all remaining callers of qemuMonitorSetMigrationCapability to use
the new qemuMonitorSetMigrationCapabilities API.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'simple' monitor tests were quite useless, since the code did not
even check whether the correct command was called.
This patch uses the QAPI schema validator to validate that the arguments
are in format according to the schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Prepare for testing of the schema of used commands by changing few
arguments to values which will not be rejected.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add a function which will allow to test whether a JSON object conforms
to the QAPI schema. This greatly helps when developing formatters for
new JSON objects and will help make sure that the code will not break in
cases which have unit tests but were actually not function-tested
(mostly various disk access protocols).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
There is a long standing hack to pass a virConnectPtr into the
qemuMonitorStartCPUs method, so that when the text monitor prompts
for a disk password, we can lookup virSecretPtr objects. This causes
us to have to pass a virConnectPtr around through countless methods
up the call chain....except some places don't have any virConnectPtr
available so have always just passed NULL. We can finally fix this
disastrous design by using virGetConnectSecret() to open a connection
to the secret driver at time of use.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.
Generated using
$ git grep -El '[[:blank:]][[:blank:]]\\$' | \
grep -E '*\.([chx]|am|mk)$$' | \
while read f; do \
sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
done
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We handle incremental storage migration in a different way. The support
for this new (as of QEMU 2.10) parameter is only needed for full
coverage of migration parameters used by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We already support several ways of setting migration bandwidth and this
is not adding another one. With this patch we are able to read and write
this parameter using query-migrate-parameters and migrate-set-parameters
in one call with all other parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The parameters used "migrate" prefix which is pretty redundant and
qemuMonitorMigrationParams structure is our internal representation of
QEMU migration parameters and it is supposed to use names which match
QEMU names.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We already support setting the maximum downtime with a dedicated
virDomainMigrateSetMaxDowntime API. This patch does not implement
another way of setting the downtime by adding a new public migration
parameter. It just makes sure any parameter we are able to get from a
QEMU monitor by query-migrate-parameters can be passed back to QEMU via
migrate-set-parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The second CHECK macro was used for string parameters. Let's rename it
to CHECK_STR and move it up to have all checks in one place.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The first CHECK macro in the test is used for checking integer values.
Let's make it a bit more generic to be usable for any numeric type and
use it for a new CHECK_INT macro.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The only remaining user of qemuMonitorGetMigrationCapability is our test
suite. Let's replace qemuMonitorGetMigrationCapability with
qemuMonitorGetMigrationCapabilities there and drop the unused function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When migration fails, QEMU may provide a description of the error in
the reply to query-migrate QMP command. We can fetch this error and use
it instead of the generic "unexpectedly failed" message.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Prior to qemu 2.5 the node names would not be generated, thus would be
missing from 'query-blockstats' and 'query-named-block-nodes'. Test that
the code correctly detects nothing.
Additionally make sure that a VM without disks does not cause problems.
The test case change is necessary as our test file checker does not play
well with empty files.
qemu 2.9 returns an extra layer in the backing data if a block job is
active. Add a test case to see whether our code properly detects and
ignores such layer.
The test data was prepared by creating a backing chain of qcow2 images
(with qemu-img and with libvirt's snapshot feature).
One of the layers was then merged back by doing a block-commit:
virsh blockcommit VM hda --top /var/lib/libvirt/images/b
and then a block-copy job was started and kept in synchronized phase:
virsh blockcopy VM hda /tmp/tgt.img --transient job
Reviewed-by: Eric Blake <eblake@redhat.com>
Add the blockstats data and fix the expected output.
Test data was created as:
qemu-img create -f qcow2 img0 10M
qemu-img create -f qcow2 -o "backing_fmt=qcow2,backing_file=img0" img1
qemu-img create -f qcow2 -o "backing_fmt=qcow2,backing_file=img1" img2
...
Reviewed-by: Eric Blake <eblake@redhat.com>
With the new approach we are actually able to correctly detect node
names for the two instances of the same backing file.
Test images were created as:
qemu-img create -f qcow2 /var/lib/libvirt/images/base.qcow2 10M
qemu-img create -f qcow2 \
-o "backing_fmt=qcow2,backing_file=/var/lib/libvirt/images/base.qcow2 \
/var/lib/libvirt/images/a.qcow2
qemu-img create -f qcow2 \
-o "backing_fmt=qcow2,backing_file=/var/lib/libvirt/images/base.qcow2 \
/var/lib/libvirt/images/b.qcow2
and then used for two separate disks.
Reviewed-by: Eric Blake <eblake@redhat.com>
We can now iterate the hash table and print all detected backing chains.
This simplifies calling of the test cases.
Reviewed-by: Eric Blake <eblake@redhat.com>
Remove the complex and unreliable code which inferred the node name
hierarchy only from data returned by 'query-named-block-nodes'. It turns
out that query-blockstats contain the full hierarchy of nodes as
perceived by qemu so the inference code is not necessary.
In query blockstats, the 'parent' object corresponds to the storage
behind a storage volume and 'backing' corresponds to the lower level of
backing chain. Since all have node names this data can be really easily
used to detect node names.
In addition to the code refactoring the one remaining test case needed
to be fixed along.
Reviewed-by: Eric Blake <eblake@redhat.com>
Extract the test prefix path into a variable and reuse
virTestLoadFileJSON to load the sample json files rather than doing it
manually.
Reviewed-by: Eric Blake <eblake@redhat.com>
The node name and backing file name can be inferred from the hierarchy.
This will also help when converting to detect node names using
query-blockstats data.
Reviewed-by: Eric Blake <eblake@redhat.com>
Rename 'json' and related variables to 'nodeNameJson'. Also rename the
test files along. This is a preparation for modifying how we detect node
names which will also require data from 'query-blockstats'.
Reviewed-by: Eric Blake <eblake@redhat.com>
Test cases named '1' and '2' differed only in the length of the backing
chain, so remove test case '2' and rename test '1' to 'basic'.
Reviewed-by: Eric Blake <eblake@redhat.com>
On domain startup, bind host or bind service can be omitted
and we will format a working command line.
Extend this to hotplug as well and specify the service to QEMU
even if the host is missing.
https://bugzilla.redhat.com/show_bug.cgi?id=1452441
vcpu properties gathered from query-hotpluggable cpus need to be passed
back to qemu. As qemu did not use the node-id property until now and
libvirt forgot to pass it back properly (it was parsed but not passed
around) we did not honor this.
This patch adds node-id to the structures where it was missing and
passes it around as necessary.
The test data was generated with a VM with following config:
<numa>
<cell id='0' cpus='0,2,4,6' memory='512000' unit='KiB'/>
<cell id='1' cpus='1,3,5,7' memory='512000' unit='KiB'/>
</numa>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1452053
oVirt uses relative names with directories in them. Test such
configuration. Also tests a snapshot done with _REUSE_EXTERNAL and a
relative backing file pre-specified in the qcow2 metadata.
Since we have to match the images by filename a common backing image
will break the detection process. Add a test case to see that the code
correctly did not continue the detection process.
Add the fields to support setting tls-creds and tls-hostname during
a migration (either source or target). Modify the query migration
function to check for the presence and set the field for future
consumers to determine which of 3 conditions is being met (NULL,
present and set to "", or present and sent to something). These
correspond to qemu commit id '4af245dc3' which added support to
default the value to "" and allow setting (or resetting) to ""
in order to disable. This reset option allows libvirt to properly
use the tls-creds and tls-hostname parameters.
Modify code paths that either allocate or use stack space in order
to call qemuMigrationParamsClear or qemuMigrationParamsFree for cleanup.
Signed-off-by: John Ferlan <jferlan@redhat.com>
qemuMonitorGetGuestCPU can now optionally create CPU data from
filtered-features in addition to feature-words.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The new API is called virCPUDataFree. Individual CPU drivers are no
longer required to implement their own freeing function unless they need
to free architecture specific data from virCPUData.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
In cases where CPU hotplug is supported by qemu force the monitor to
reject invalid or broken responses to 'query-cpus'. It's expected that
the command returns usable data in such case.
QEMU 2.8.0 adds support for unavailable-features in
query-cpu-definitions reply. The unavailable-features array lists CPU
features which prevent a corresponding CPU model from being usable on
current host. It can only be used when all the unavailable features are
disabled. Empty array means the CPU model can be used without
modifications.
We can use unavailable-features for providing CPU model usability info
in domain capabilities XML:
<domainCapabilities>
...
<cpu>
<mode name='host-passthrough' supported='yes'/>
<mode name='host-model' supported='yes'>
<model fallback='allow'>Skylake-Client</model>
...
</mode>
<mode name='custom' supported='yes'>
<model usable='yes'>qemu64</model>
<model usable='yes'>qemu32</model>
<model usable='no'>phenom</model>
<model usable='yes'>pentium3</model>
<model usable='yes'>pentium2</model>
<model usable='yes'>pentium</model>
<model usable='yes'>n270</model>
<model usable='yes'>kvm64</model>
<model usable='yes'>kvm32</model>
<model usable='yes'>coreduo</model>
<model usable='yes'>core2duo</model>
<model usable='no'>athlon</model>
<model usable='yes'>Westmere</model>
<model usable='yes'>Skylake-Client</model>
...
</mode>
</cpu>
...
</domainCapabilities>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:
virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix
We can do better:
virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit 3f71c79768 added 'qemu_id' field to track the id of the cpu
as reported by query-cpus. The patch did not include changes necessary
to propagate the id through the functions matching the data to the
libvirt cpu structures and thus all vcpus had id 0.
The field is named 'enable_id' in other structures and a patch recently
added 'qemu_id' which has different semantics. To avoid confusion in the
tests rename the field.
Add support for a duration/length for the bps/iops and friends.
Modify the API in order to add the "blkdeviotune." specific definitions
for the iotune throttling duration/length options
total_bytes_sec_max_length
write_bytes_sec_max_length
read_bytes_sec_max_length
total_iops_sec_max_length
write_iops_sec_max_length
read_iops_sec_max_length
Extended the qemuMonitorCPUInfo with a halted flag. Extract the halted
flag for both text and JSON monitor.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Since introduction of chardev hotplug the code was wrong for the UDP
case and basically created a TCP socket instead. Use proper objects and
type for UDP.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1377602
Until now the test was rather useless since it didn't check the
arguments formatted and didn't use properly configured chardev objects.
Add the expected arguments and instrument the test to validate them.
Modify some test cases to actually add valid data.
Note that the UDP test data is currently wrong due to a bug.
The chardev attach test would do all the tests in one virTestRun
instance. If one sub-test failed then the test would report failure
improperly and the error would be hard to debug since the error pointer
was overwritten.
The list of supported CPU models in domain capabilities is stored in
virDomainCapsCPUModels. Let's use the same object for storing CPU models
in QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Return whether a vcpu entry is hotpluggable or online so that upper
layers don't have to infer the information from other data.
Advantage is that this code can be tested by unit tests.
Power 8 platform's basic hotpluggable unit is a core rather than a
thread for x86_64 family. This introduces most of the complexity of the
matching code and thus needs to be tested.
The test data contain data captured from in-order cpu hotplug and
unplug operations.
During review it was reported that adding at least 11 vcpus creates a
collision of prefixes in the monitor matching algorithm. Add a test case
to verify that the problem won't happen.
As the combination algorithm is rather complex and ugly it's necessary
to make sure it works properly. Add test suite infrastructure for
testing it along with a basic test based on x86_64 platform.
To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.
Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.
The first argument should be const char ** instead of
char **, because this is a search function and as such it
doesn't, and shouldn't, alter the haystack in any way.
This change means we no longer have to cast arrays of
immutable strings to arrays of mutable strings; we still
have to do the opposite, though, but that's reasonable.
Rather than pass the disks[i]->info.alias to qemuMonitorSetDrivePassphrase
and then generate the "drive-%s" alias from that, let's use qemuAliasFromDisk
prior to the call to generate the drive alias and then pass that along
thus removing the need to generate the alias from the monitor code.
qemuMonitorMigrationParams is a better name for a structure which
contains various migration parameters. While doing that, we should use
full names for individual parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1298070
We have the code for attaching redirdevs for ages now.
Unfortunately, our monitor code that handles talking to the qemu
process was missing a little piece of code that actually enabled
the feature.
BTW: it really is called "type" on the monitor, even though it's
called "name" on the cmd line. Don't ask.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Extract whether a given drive has a tray and whether there is no image
inserted.
Negative logic for the image insertion is chosen so that the flag is set
only if we are certain of the fact.
The structure actually contains migration statistics rather than just
the status as the name suggests. Renaming it as
qemuMonitorMigrationStats removes the confusion.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We use the function to create a virDomainXMLOption object that is
required for some functions. However, we don't pass the driver
pointer to the object anywhere - rather than pass NULL. This
causes trouble later when parsing a domain XML and calling post
parse callbacks:
Program received signal SIGSEGV, Segmentation fault.
0x000000000043fa3e in qemuDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, opaque=0x0) at qemu/qemu_domain.c:1043
1043 qemuCaps = virQEMUCapsCacheLookup(driver->qemuCapsCache, def->emulator);
(gdb) bt
#0 0x000000000043fa3e in qemuDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, opaque=0x0) at qemu/qemu_domain.c:1043
#1 0x00007ffff2928bf9 in virDomainDefPostParse (def=0x7d36c0, caps=0x7caf10, xmlopt=0x7c82c0) at conf/domain_conf.c:4269
#2 0x00007ffff294de04 in virDomainDefParseXML (xml=0x7da8c0, root=0x7dab80, ctxt=0x7da980, caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16400
#3 0x00007ffff294e5b5 in virDomainDefParseNode (xml=0x7da8c0, root=0x7dab80, caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16582
#4 0x00007ffff294e424 in virDomainDefParse (xmlStr=0x0, filename=0x7c7ef0 "/home/zippy/work/libvirt/libvirt.git/tests/securityselinuxlabeldata/disks.xml", caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16529
#5 0x00007ffff294e4b2 in virDomainDefParseFile (filename=0x7c7ef0 "/home/zippy/work/libvirt/libvirt.git/tests/securityselinuxlabeldata/disks.xml", caps=0x7caf10, xmlopt=0x7c82c0, flags=0) at conf/domain_conf.c:16553
#6 0x00000000004303ca in testSELinuxLoadDef (testname=0x53c929 "disks") at securityselinuxlabeltest.c:192
#7 0x00000000004309e8 in testSELinuxLabeling (opaque=0x53c929) at securityselinuxlabeltest.c:313
#8 0x0000000000431207 in virtTestRun (title=0x53c92f "Labelling \"disks\"", body=0x430964 <testSELinuxLabeling>, data=0x53c929) at testutils.c:211
#9 0x0000000000430c5d in mymain () at securityselinuxlabeltest.c:373
#10 0x00000000004325c2 in virtTestMain (argc=1, argv=0x7fffffffd7e8, func=0x430b4a <mymain>) at testutils.c:863
#11 0x0000000000430deb in main (argc=1, argv=0x7fffffffd7e8) at securityselinuxlabeltest.c:381
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Instead of using qemuMonitorJSONDevGetBlockExtent (which I plan to
remove later) extract the data in place.
Additionally add a flag that will be set when the wr_highest_offset was
extracted correctly so that callers can act according to that.
The test case addition should help make sure that everything works.
QEMU_CAPS_SEAMLESS_MIGRATION capability says QEMU supports
SPICE_MIGRATE_COMPLETED event. Thus we can just drop all code which
polls query-spice and replace it with waiting for the event.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The free callback should be qemuMonitorChardevInfoFree rather
than just 'free' when virHashCreate'ing the chardevInfo hash.
==29959== 24 bytes in 2 blocks are definitely lost in loss record 19 of 53
==29959== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29959== by 0xB95C679: strdup (in /lib64/libc-2.20.so)
==29959== by 0x63C6546: virStrdup (virstring.c:709)
==29959== by 0x4805ED: qemuMonitorJSONExtractChardevInfo (qemu_monitor_json.c:3429)
==29959== by 0x4807A5: qemuMonitorJSONGetChardevInfo (qemu_monitor_json.c:3479)
==29959== by 0x434AEC: testQemuMonitorJSONqemuMonitorJSONGetChardevInfo (qemumonitorjsontest.c:1824)
==29959== by 0x436F2F: virtTestRun (testutils.c:211)
==29959== by 0x436932: mymain (qemumonitorjsontest.c:2404)
==29959== by 0x4382EA: virtTestMain (testutils.c:863)
==29959== by 0x436B27: main (qemumonitorjsontest.c:2423)
Signed-off-by: Zhang Bo <oscar.zhangbo@huawei.com>
Signed-off-by: Zhou Yimin <zhouyimin@huawei.com>
Rather than have a separate routine to parse the alias of an iothread
returned from qemu in order to get the iothread_id value, parse the alias
when returning and just return the iothread_id in qemuMonitorIOThreadInfoPtr
This set of patches removes the function, changes the "char *name" to
"unsigned int" and handles all the fallout.
Use the new single function instead of calling
qemuMonitorJSONGetBlockStatsInfo and
qemuMonitorJSONGetBlockStatsParamsNumber. This will allow to delete the
functions later while still maintaining coverage.
When trying clang, it found out that we were comparing sizeof with 0
even though we wanted to check the return value of memcmp. That showed
us that the test was wrong and it needs a fix as well.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Improve the monitor function to also retrieve the guest state of
character device (if provided) so that we can refresh the state of
virtio-serial channels and perhaps react to changes in the state in
future patches.
This patch changes the returned data from qemuMonitorGetChardevInfo to
return a structure containing the pty path and the state for all the
character devices.
The change to the testsuite makes sure that the data is parsed
correctly.
To unify future additions that require information from "query-chardev"
rename qemuMonitorGetPtyPaths and friends to qemuMonitorGetChardevInfo
and move the allocation of the returned hash into the top level
function.
We used to set migration capabilities only when a user asked for them in
flags. This is fine when migration succeeds since the QEMU process is
killed in the end but in case migration fails or if it's cancelled, some
capabilities may remain turned on with no way to turn them off. To fix
that, migration capabilities have to be turned on if requested but
explicitly turned off in case they were not requested but QEMU supports
them.
https://bugzilla.redhat.com/show_bug.cgi?id=1163953
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Add support for bps_max and friends in the driver part.
In the part checking if a qemu is running, check if the running binary
support bps_max, if not print an error message, if yes add it to
"info" variable
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Modify the structure _virDomainBlockIoTuneInfo to support these the new
options.
Change the initialization of the variable expectedInfo in qemumonitorjsontest.c
to avoid compiling problem.
Add documentation about the new xml options
Signed-off-by: Matthias Gatto <matthias.gatto@outscale.com>
Upstream qemu 1.4 added some drive-mirror tunables not present
when it was first introduced in 1.3. Management apps may want
to set these in some cases (for example, without tuning
granularity down to sector size, a copy may end up occupying
more bytes than the original because an entire cluster is
copied even when only a sector within the cluster is dirty,
although tuning it down results in more CPU time to do the
copy). I haven't personally needed to use the parameters, but
since they exist, and since the new API supports virTypedParams,
we might as well expose them.
Since the tuning parameters aren't often used, and omitted from
the QMP command when unspecified, I think it is safe to rely on
qemu 1.3 to issue an error about them being unsupported, rather
than trying to create a new capability bit in libvirt.
Meanwhile, all versions of qemu from 1.4 to 2.1 have a bug where
a bad granularity (such as non-power-of-2) gives a poor message:
error: internal error: unable to execute QEMU command 'drive-mirror': Invalid parameter 'drive-virtio-disk0'
because of abuse of QERR_INVALID_PARAMETER (which is supposed to
name the parameter that was given a bad value, rather than the
value passed to some other parameter). I don't see that a
capability check will help, so we'll just live with it (and it
has since been improved in upstream qemu).
* src/qemu/qemu_monitor.h (qemuMonitorDriveMirror): Add
parameters.
* src/qemu/qemu_monitor.c (qemuMonitorDriveMirror): Likewise.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror):
Likewise.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONDriveMirror):
Likewise.
* src/qemu/qemu_driver.c (qemuDomainBlockCopyCommon): Likewise.
(qemuDomainBlockRebase, qemuDomainBlockCopy): Adjust callers.
* src/qemu/qemu_migration.c (qemuMigrationDriveMirror): Likewise.
* tests/qemumonitorjsontest.c (qemuMonitorJSONDriveMirror): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1103245
An advice appeared there on the qemu-devel list [1]. When a domain is
suspended and then resumed guest kernel is not aware of this. So we've
introduced virDomainSetTime API that resets the time within guest
using qemu-ga. On the other hand, qemu itself is trying to make RTC
beat faster to catch the difference. But if we don't tell qemu that
guest's time was reset via the other method, both mechanisms are
applied resulting in again wrong guest time. In order to avoid summing
both corrections we need to tell qemu that it should not use the RTC
injection if the guest time is set via guest agent.
1: http://www.mail-archive.com/qemu-devel@nongnu.org/msg236435.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
That can be lately achieved with by having .param == NULL in the
virQEMUCapsCommandLineProps struct.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
To allow changing the name that is recorded in the overlay of the TOP
image used in a block commit operation, we need to specify the backing
name to qemu. This is done via the "backing-file" attribute to the
block-commit command.
We are about to turn on support for active block commit. Although
qemu 2.0 was the first version to mostly support it, that version
mis-handles 0-length files, and doesn't have anything available for
easy probing. But qemu 2.1 fixed bugs, and made life simpler by
letting the 'top' argument be optional. Unless someone begs for
active commit with qemu 2.0, for now we are just going to enable
it only by probing for qemu 2.1 behavior (anyone backporting active
commit can also backport the optional argument behavior). This
requires qemu.git commit 7676e2c597000eff3a7233b40cca768b358f9bc9.
Although all our actual uses of block-commit supply arguments for
both base and top, we can omit both arguments and use a bogus
device string to trigger an interesting behavior in qemu. All QMP
commands first do argument validation, failing with GenericError
if a mandatory argument is missing. Once that passes, the code
in the specific command gets to do further checking, and the qemu
developers made sure that if device is the only supplied argument,
then the block-commit code will look up the device first, with a
failure of DeviceNotFound, before attempting any further argument
validation (most other validations fail with GenericError). Thus,
the category of error class can reliably be used to decipher
whether the top argument was optional, which in turn implies a
working active commit. Since we expect our bogus device string to
trigger an error either way, the code is written to return a
distinct return value without spamming the logs.
* src/qemu/qemu_monitor.h (qemuMonitorSupportsActiveCommit): New
prototype.
* src/qemu/qemu_monitor.c (qemuMonitorSupportsActiveCommit):
Implement it.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockCommit):
Allow NULL for top and base, for probing purposes.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockCommit):
Likewise, implementing the probe.
* tests/qemumonitorjsontest.c (mymain): Enable...
(testQemuMonitorJSONqemuMonitorSupportsActiveCommit): ...a new test.
Signed-off-by: Eric Blake <eblake@redhat.com>
qemuMonitorJSONSendKey declares the "holdtime" argument as unsigned int
while the command was constructed in qemuMonitorJSONMakeCommand using
the "P" modifier which took a unsigned long from the variable
arguments which then made it possible to access uninitialized memory.
This broke the qemumonitorjsontest on 32bit fedora 20:
64) qemuMonitorJSONSendKey
... libvirt: QEMU Driver error : internal error: unsupported data type 'W' for arg 'WVSì D$0èwÿÿÃAå' FAILED
Uncovered by upstream commit f744b831c6.
Additionally add test for the hold-time option.
I almost wrote a hash value free function that just called
VIR_FREE, then realized I couldn't be the first person to
do that. Sure enough, it was worth factoring into a common
helper routine.
* src/util/virhash.h (virHashValueFree): New function.
* src/util/virhash.c (virHashValueFree): Implement it.
* src/util/virobject.h (virObjectFreeHashData): New function.
* src/libvirt_private.syms (virhash.h, virobject.h): Export them.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnInit): Use
common function.
* src/qemu/qemu_capabilities.c (virQEMUCapsCacheNew): Likewise.
* src/qemu/qemu_command.c (qemuDomainCCWAddressSetCreate):
Likewise.
* src/qemu/qemu_monitor.c (qemuMonitorGetBlockInfo): Likewise.
* src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise.
* src/util/virclosecallbacks.c (virCloseCallbacksNew): Likewise.
* src/util/virkeyfile.c (virKeyFileParseGroup): Likewise.
* tests/qemumonitorjsontest.c
(testQemuMonitorJSONqemuMonitorJSONGetBlockInfo): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
This patch adds qemuMonitorGetDumpGuestMemoryCapability, which is used to check
whether the specified dump-guest-memory format is supported by qemu.
Signed-off-by: Qiao Nuohan <qiaonuohan@cn.fujitsu.com>
In the 730af8f2cd commit we are fixing broken qemu startup on systems
with ancient qemu. This commit introduces the regression test for that
specific case to make sure we don't break it again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The QOM path in qemu that contains the CPUID registers of a running VM
may not be present (introduced in QEMU 1.5).
Since commit d94b781771 we have a regression with QEMU that don't
support reporting of the CPUID register state via the monitor as the
process startup code expects the path to exist.
This patch adds code that checks with the monitor if the requested path
already exists and uses it only in this case.
The qemu monitor supports retrieval of actual CPUID bits presented to
the guest using QMP monitor. Add APIs to extract these information and
tests for them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can). But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).
Fix up offenders in the testsuite.
* tests/cputest.c (cpuTestCompareXML): Use intended type.
* tests/qemucapabilitiestest.c (testQemuCaps): Likewise.
* tests/qemumonitorjsontest.c: Drop const.
Signed-off-by: Eric Blake <eblake@redhat.com>
So far, we're unit testing some basic functions and some (so called)
simple functions (e.g. "qmp_capabilities", "system_powerdown"). However,
there are more functions which expect simple "{'return': {}}" reply, but
takes more args to construct the command (for instance "set_link"). This
patch aims on such functions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The test case average timing code has not been used by any test
case ever. Delete it to remove complexity.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
qemumonitorjsontest.c: In function 'testQemuMonitorJSONqemuMonitorJSONGetBalloonInfo':
qemumonitorjsontest.c:1134: warning: integer constant is too large for 'long' type
* tests/qemumonitorjsontest.c
(testQemuMonitorJSONqemuMonitorJSONGetBalloonInfo)
(testQemuMonitorJSONqemuMonitorJSONGetBlockStatsInfo): Use correct
type.
Signed-off-by: Eric Blake <eblake@redhat.com>
Right now, we are testing qemuMonitorSystemPowerdown instead of
qemuMonitorJSONSystemPowerdown. It makes no harm, as both functions have
the same header and the former is just a wrapper over the latter. But we
should be consistent as we're testing the JSON functions only in here.
This macro is there to test the simplest monitor functions we have,
those in the form of: int ( *func) (qemuMonitorPtr). So far, we have
seven such functions.
