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.
QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.
When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.
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.
Turn various vshPrint() informative messages into vshPrintExtra(), so
they are not printed when requesting the quiet mode; neither XML/info
outputs nor the results of commands are affected.
Also change the expected outputs of the virsh-undefine test, since virsh
is invoked in quiet mode there.
Some informative messages might still be converted (and thus silenced
when in quiet mode), but this is an improvements nonetheless.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358179
For some unknown reason the original implementation of the <forwarder>
element only took advantage of part of the functionality in the
dnsmasq feature it exposes - it allowed specifying the ip address of a
DNS server which *all* DNS requests would be forwarded to, like this:
<forwarder addr='192.168.123.25'/>
This is a frontend for dnsmasq's "server" option, which also allows
you to specify a domain that must be matched in order for a request to
be forwarded to a particular server. This patch adds support for
specifying the domain. For example:
<forwarder domain='example.com' addr='192.168.1.1'/>
<forwarder domain='www.example.com'/>
<forwarder domain='travesty.org' addr='10.0.0.1'/>
would forward requests for bob.example.com, ftp.example.com and
joe.corp.example.com all to the DNS server at 192.168.1.1, but would
forward requests for travesty.org and www.travesty.org to
10.0.0.1. And due to the second line, requests for www.example.com,
and odd.www.example.com would be resolved by the libvirt network's own
DNS server (i.e. thery wouldn't be immediately forwarded) even though
they also match 'example.com' - the match is given to the entry with
the longest matching domain. DNS requests not matching any of the
entries would be resolved by the libvirt network's own DNS server.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1331796
If you define a libvirt virtual network with one or more IP addresses,
it starts up an instance of dnsmasq. It's always been possible to
avoid dnsmasq's dhcp server (simply don't include a <dhcp> element),
but until now it wasn't possible to avoid having the DNS server
listening; even if the network has no <dns> element, it is started
using default settings.
This patch adds a new attribute to <dns>: enable='yes|no'. For
backward compatibility, it defaults to 'yes', but if you don't want a
DNS server created for the network, you can simply add:
<dns enable='no'/>
to the network configuration, and next time the network is started
there will be no dns server created (if there is dhcp configuration,
dnsmasq will be started with "port=0" which disables the DNS server;
if there is no dhcp configuration, dnsmasq won't be started at all).
The new forward mode 'open' is just like mode='route', except that no
firewall rules are added to assure that any traffic does or doesn't
pass. It is assumed that either they aren't necessary, or they will be
setup outside the scope of libvirt.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=846810
==18324== 32 bytes in 1 blocks are still reachable in loss record 41 of 114
==18324== at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==18324== by 0x4EA479B: virAlloc (viralloc.c:144)
==18324== by 0x4EA674A: virBitmapNewQuiet (virbitmap.c:77)
==18324== by 0x4EA67F7: virBitmapNew (virbitmap.c:106)
==18324== by 0x4EC777D: dnsmasqCapsNewEmpty (virdnsmasq.c:801)
==18324== by 0x4EC781B: dnsmasqCapsNewFromBuffer (virdnsmasq.c:815)
==18324== by 0x407CF4: mymain (networkxml2conftest.c:99)
==18324== by 0x409CF0: virTestMain (testutils.c:982)
==18324== by 0x4080EA: main (networkxml2conftest.c:136)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The script was returning success unless it failed on the last file.
This went unnoticed because sc_prohibit_long_lines forbids lines
longer than 90 characters in .arg[sv] files.
Check whether the disable-legacy property is present on the following
devices:
virtio-balloon-pci
virtio-blk-pci
virtio-scsi-pci
virtio-serial-pci
virtio-9p-pci
virtio-net-pci
virtio-rng-pci
virtio-gpu-pci
virtio-input-host-pci
virtio-keyboard-pci
virtio-mouse-pci
virtio-tablet-pci
Assuming that if QEMU knows other virtio devices where this property
is applicable, it will have at least one of these devices.
Added in QEMU by:
commit e266d421490e0ae83044bbebb209b2d3650c0ba6
virtio-pci: add flags to enable/disable legacy/modern
https://bugzilla.redhat.com/show_bug.cgi?id=1182074
Since libvirt still uses a legacy qemu arg format to add a disk, the
manner in which the 'password-secret' argument is passed to qemu needs
to change to prepend a 'file.' If in the future, usage of the more
modern disk format, then the prepended 'file.' can be removed.
Fix based on Jim Fehlig <jfehlig@suse.com> posting and subsequent
upstream list followups, see:
http://www.redhat.com/archives/libvir-list/2016-August/msg00777.html
for details. Introduced by commit id 'a1344f70'.
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.
If any of the devices referenced a USB hub that does not exist,
defining the domain would either fail with:
error: An error occurred, but the cause is unknown
(if only the last hub in the path is missing)
or crash.
Return a proper error instead of crashing.
https://bugzilla.redhat.com/show_bug.cgi?id=1367130
Commit 11567cf added some libxl tests into domaincapstest and
added libvirt_driver_libxl_impl.la to domaincapstest_LDADD.
This causes link fail on systems without GNU regex implementation:
gmake[2]: Entering directory '/usr/home/novel/code/libvirt/tests'
CCLD domaincapstest
../src/.libs/libvirt_driver_libxl_impl.a(libvirt_driver_libxl_impl_la-libxl_capabilities.o):
In function `libxlMakeCapabilities':
libxl/libxl_capabilities.c:(.text+0x6b2): undefined reference to
`rpl_regcomp'
libxl/libxl_capabilities.c:(.text+0x6d0): undefined reference to
`rpl_regerror'
libxl/libxl_capabilities.c:(.text+0x803): undefined reference to
`rpl_regexec'
libxl/libxl_capabilities.c:(.text+0xa58): undefined reference to
`rpl_regfree'
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)
This happens because on these system it tries to use gnulib's builtin
regex implementation, but doesn't link to gnulib.
Fix by adding $(GNULIB_LIBS) along with libvirt_driver_libxl_impl.la to
domaincapstest_LDADD.
It may happen that a developer wants to run just a specific
subset of tests:
tests $ VIR_TEST_RANGE=22 ../run ./virschematest
This now fails miserably:
==6840== Invalid read of size 8
==6840== at 0x4F397C0: virXMLValidatorValidate (virxml.c:1216)
==6840== by 0x402B72: testSchemaFile (virschematest.c:53)
==6840== by 0x403737: virTestRun (testutils.c:180)
==6840== by 0x402CF5: testSchemaDir (virschematest.c:98)
==6840== by 0x402EB1: testSchemaDirs (virschematest.c:131)
==6840== by 0x40314D: mymain (virschematest.c:194)
==6840== by 0x4051AF: virTestMain (testutils.c:982)
==6840== by 0x4035A9: main (virschematest.c:217)
==6840== Address 0x10 is not stack'd, malloc'd or (recently) free'd
Problem is, we are trying to do two types of tests here: validate
RNG schema itself, and validate XML files against RNG schemas.
And the latter tries to re-use a resource allocated in the
former. Therefore if the former is skipped (due to
VIR_TEST_RANGE) we have to allocate the resource manually.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When the user doesn't specify any model for a USB controller,
we use an architecture-dependent default, but we don't reflect
it in the guest XML.
Pick the default USB controller model when parsing the guest
XML instead of when creating the QEMU command line, so that
our choice is saved back to disk.
==8630== Invalid read of size 8
==8630== at 0x4EA4F0F: virFree (viralloc.c:582)
==8630== by 0x4F398F0: virXMLValidatorFree (virxml.c:1257)
==8630== by 0x40305C: mymain (virschematest.c:191)
==8630== by 0x405159: virTestMain (testutils.c:982)
==8630== by 0x403553: main (virschematest.c:215)
==8630== Address 0xcd72243 is 131 bytes inside a block of size 177 free'd
==8630== at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==8630== by 0x4EA4F19: virFree (viralloc.c:582)
==8630== by 0x4ED0973: virFindFileInPath (virfile.c:1646)
==8630== by 0x405149: virTestMain (testutils.c:980)
==8630== by 0x403553: main (virschematest.c:215)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1353296
On UNIX like systems there are no constraints on what characters
can be in file/dir names (except for NULL, obviously). Moreover,
some values that we think of as paths (e.g. disk source) are not
necessarily paths at all. For instance, some hypervisors take
that as an arbitrary identifier and corresponding file is then
looked up by hypervisor in its table. Instead of trying to fix
our regular expressions (and forgetting to include yet another
character there), lets drop the validation completely.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
More misunderstanding/mistaken assumptions on my part - I had thought
that a pci-expander-bus could be plugged into any legacy PCI slot, and
that pcie-expander-bus could be plugged into any PCIe slot. This isn't
correct - they can both be plugged ontly into their respective root
buses. This patch adds that restriction.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1358712
libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
normal PCIe endpoint can be connected, but this is wrong - it will
only work if it's plugged into pcie-root (the PCIe root complex) or a
pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
connection flags accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1363648
Since the introduction of CMT features (commit v1.3.5-461-gf294b83)
starting a domain with host-model CPU on a host which supports CMT fails
because QEMU complains about unknown 'cmt' feature:
qemu-system-x86_64: CPU feature cmt not found
https://bugzilla.redhat.com/show_bug.cgi?id=1355857
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The generated command line wouldn't work since QEMU doesn't know what
'cmt' is. The following patch will fix this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1355857
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
In qemu, enabling this feature boils down to adding the following
onto the command line:
-global driver=cfi.pflash01,property=secure,value=on
However, there are some constraints resulting from the
implementation. For instance, System Management Mode (SMM) is
required to be enabled, the machine type must be q35-2.4 or
later, and the guest should be x86_64. While technically it is
possible to have 32 bit guests with secure boot, some non-trivial
CPU flags tuning is required (for instance lm and nx flags must
be prohibited). Given complexity of our CPU driver, this is not
trivial. Therefore I've chosen to forbid 32 bit guests for now.
If there's ever need, we can refine the check later.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This element will control secure boot implemented by some
firmwares. If the firmware used in <loader/> does support the
feature we must tell it to the underlying hypervisor. However, we
can't know whether loader does support it or not just by looking
at the file. Therefore we have to have an attribute to the
element where users can tell us whether the firmware is secure
boot enabled or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Since its release of 2.4.0 qemu is able to enable System
Management Module in the firmware, or disable it. We should
expose this capability in the XML. Unfortunately, there's no good
way to determine whether the binary we are talking to supports
it. I mean, if qemu's run with real machine type, the smm
attribute can be seen in 'qom-list /machine' output. But it's not
there when qemu's run with -M none. Therefore we're stuck with
version based check.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
A bunch of cases were only being tested for WHEN_ACTIVE or
WHEN_INACTIVE. Use WHEN_BOTH for all except the very few that
actually require the existing setup.
At the beginning of the test, some preparation work is done. For
instance new virSecurityManager is created. If this fails for
whatever reason, we try to fetch the latest error and print the
error message contained in it. However, if there's a bug in our
code and no error is reported, this approach will lead to crash,
while with virGetLastErrorMessage() it won't.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1356937
Add the definitions to allow for viewing/setting cgroup period and quota
limits for IOThreads.
This is similar to the work done for emulator quota and period by
commit ids 'b65dafa' and 'e051c482'.
Being able to view/set the IOThread specific values is related to more
recent changes adding global period (commmit id '4d92d58f') and global
quota (commit id '55ecdae') definitions and qemu support (commit id
'4e17ff79' and 'fbcbd1b2'). With a global setting though, if somehow
the IOThread value in the cgroup hierarchy was set "outside of libvirt"
to a value that is incompatible with the global value.
Allowing control over IOThread specific values provides the capability
to alter the IOThread values as necessary.
Failure to parse the schema file would not trigger a test suite failure.
In addition to making the test fail it's necessary to split up the
parsing of the schema file into a separate test.
This is necessary as the XML validator uses libvirt errors to report
problems parsing of the actual schema RNG needs to be split out into a
separate function and called via virTestRun which has the
infrastructure to report them.
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.
libxl configuration files conversion can now handle USB controllers.
When parting libxl config file, USB controllers with type PV are
ignored as those aren't handled.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
==2064442== 200 (88 direct, 112 indirect) bytes in 1 blocks are definitely lost in loss record 54 of 73
==2064442== at 0x4C2E0F0: calloc (vg_replace_malloc.c:711)
==2064442== by 0x18E75B80: virAllocVar (viralloc.c:560)
==2064442== by 0x18EC43B0: virObjectNew (virobject.c:193)
==2064442== by 0x18EC476E: virObjectLockableNew (virobject.c:219)
==2064442== by 0x1906BC73: virSecurityManagerNewDriver (security_manager.c:93)
==2064442== by 0x1906C076: virSecurityManagerNewStack (security_manager.c:115)
==2064442== by 0x43CC39: qemuTestDriverInit (testutilsqemu.c:548)
==2064442== by 0x4337ED: mymain (qemumonitorjsontest.c:2440)
==2064442== by 0x43BABE: virTestMain (testutils.c:982)
==2064442== by 0x43A490: main (qemumonitorjsontest.c:2558)
The current LUKS support has a "luks" volume type which has
a "luks" encryption format.
This partially makes sense if you consider the QEMU shorthand
syntax only requires you to specify a format=luks, and it'll
automagically uses "raw" as the next level driver. QEMU will
however let you override the "raw" with any other driver it
supports (vmdk, qcow, rbd, iscsi, etc, etc)
IOW the intention though is that the "luks" encryption format
is applied to all disk formats (whether raw, qcow2, rbd, gluster
or whatever). As such it doesn't make much sense for libvirt
to say the volume type is "luks" - we should be saying that it
is a "raw" file, but with "luks" encryption applied.
IOW, when creating a storage volume we should use this XML
<volume>
<name>demo.raw</name>
<capacity>5368709120</capacity>
<target>
<format type='raw'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</target>
</volume>
and when configuring a guest disk we should use
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/home/berrange/VirtualMachines/demo.raw'/>
<target dev='sda' bus='scsi'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</disk>
This commit thus removes the "luks" storage volume type added
in
commit 318ebb36f1
Author: John Ferlan <jferlan@redhat.com>
Date: Tue Jun 21 12:59:54 2016 -0400
util: Add 'luks' to the FileTypeInfo
The storage file probing code is modified so that it can probe
the actual encryption formats explicitly, rather than merely
probing existance of encryption and letting the storage driver
guess the format.
The rest of the code is then adapted to deal with
VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS
instead of just VIR_STORAGE_FILE_LUKS.
The commit mentioned above was included in libvirt v2.0.0.
So when querying volume XML this will be a change in behaviour
vs the 2.0.0 release - it'll report 'raw' instead of 'luks'
for the volume format, but still report 'luks' for encryption
format. I think this change is OK because the storage driver
did not include any support for creating volumes, nor starting
guets with luks volumes in v2.0.0 - that only since then.
Clearly if we change this we must do it before v2.1.0 though.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
To allow using failover with gluster it's necessary to specify multiple
volume hosts. Add support for starting qemu with such configurations.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add support for converting objects nested in arrays with a numbering
discriminator on the command line. This syntax is used for the
object-based specification of disk source properties.
Add a modular parser that will allow to parse 'json' backing definitions
that are supported by qemu. The initial implementation adds support for
the 'file' driver.
Due to the approach qemu took to implement the JSON backing strings it's
possible to specify them in two approaches.
The object approach:
json:{ "file" : { "driver":"file",
"filename":"/path/to/file"
}
}
And a partially flattened approach:
json:{"file.driver":"file"
"file.filename":"/path/to/file"
}
Both of the above are supported by qemu and by the code added in this
commit. The current implementation de-flattens the first level ('file.')
if possible and required. Other handling may be added later but
currently only one level was possible anyways.
For use with memory hotplug virQEMUBuildCommandLineJSONRecurse attempted
to format JSON arrays as bitmap on the command line. Make the formatter
function configurable so that it can be reused with different syntaxes
of arrays such as numbered arrays for use with disk sources.
This patch extracts the code and adds a parameter for the function that
will allow to plug in different formatters.
Until now the JSON->commandline convertor was used only for objects
created by qemu. To allow reusing it with disk formatter we'll need to
escape ',' as usual in qemu commandlines.
Refactor the command line generator by adding a wrapper (with
documentation) that will handle the outermost object iteration.
This patch also renames the functions and tweaks the error message for
nested arrays to be more universal.
The new function is then reused to simplify qemucommandutiltest.
As we already test that the extraction of the backing store string works
well additional tests for the backing store string parser can be made
simpler.
Export virStorageSourceNewFromBackingAbsolute and use it to parse the
backing store strings, format them using virDomainDiskSourceFormat and
match them against expected XMLs.
Failure to parse a XML that was not supposed to fail would result into a
crash in the test suite as the vcpu bitmap would not be filled prior to
the active XML->XML test.
Skip formatting of the vcpu snippet in the fake status XML formatter in
such case to avoid the crash. The test would fail anyways.
There's a plan to rework the address handling, so testcases
that verify hotplugging ccw devices will help in avoiding
regression.
In this commit, some files are duplicated because of the way
qemuhotplug.c calculates the expected xml filenames.
I plan on changing that to explicitly stating the basis domain
xml, the device xml, and the expected xml.
When parsing a command line with USB devices that have
no address specified, QEMU automatically adds a USB hub
if the device would fill up all the available USB ports.
To help most of the users, add one hub if there are more
USB devices than available ports. For wilder configurations,
expect the user to provide us with more hubs and/or controllers.
Resolves a CI test integration failure with a RHEL6/Centos6 environment.
In order to use a LUKS encrypted device, the design decision was to
generate an encrypted secret based on the master key. However, commit
id 'da86c6c' missed checking for that specifically.
When qemuDomainSecretSetup was implemented, a design decision was made
to "fall back" to a plain text secret setup if the specific cipher was
not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC))
as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup
there is no fall back to the plaintext secret, thus if that gets set
up by qemuDomainSecretSetup, then we need to fail.
Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET
bit, it didn't take into account the second requirement that the
ability to generate the encrypted secret is possible. So modify the
test to not attempt to run the luks-disk if we know we don't have
the encryption algorithm.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1301021
Generate the luks command line using the AES secret key to encrypt the
luks secret. A luks secret object will be in addition to a an AES secret.
For hotplug, check if the encinfo exists and if so, add the AES secret
for the passphrase for the secret object used to decrypt the device.
Modify/augment the fakeSecret* in qemuxml2argvtest in order to handle
find a uuid or a volume usage with a specific path prefix in the XML
(corresponds to the already generated XML tests). Add error message
when the 'usageID' is not 'mycluster_myname'. Commit id '1d632c39'
altered the error message generation to rely on the errors from the
secret_driver (or it's faked replacement).
Add the .args output for adding the LUKS disk to the domain
Signed-off-by: John Ferlan <jferlan@redhat.com>
Partially resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1301021
If the volume xml was looking to create a luks volume take the necessary
steps in order to make that happen.
The processing will be:
1. create a temporary file (virStorageBackendCreateQemuImgSecretPath)
1a. use the storage driver state dir path that uses the pool and
volume name as a base.
2. create a secret object (virStorageBackendCreateQemuImgSecretObject)
2a. use an alias combinding the volume name and "_luks0"
2b. add the file to the object
3. create/add luks options to the commandline (virQEMUBuildLuksOpts)
3a. at the very least a "key-secret=%s" using the secret object alias
3b. if found in the XML the various "cipher" and "ivgen" options
Signed-off-by: John Ferlan <jferlan@redhat.com>
Cannot assume virGetLastError returns non-NULL value - modify the code to
fetch err and check if err && err->code
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
We were requiring a USB port path in the schema, but not enforcing it.
Omitting the USB port would lead to libvirt formatting it as (null).
Such domain cannot be started and will disappear after libvirtd restart
(since it cannot parse back the XML).
Only format the port if it has been specified and mark it as optional
in the XML schema.
Commit id's '9bbf0d7e6' and '2552fec24' added some XML parsing tests
for a LUKS volume to use a 'passphrase' secret format. After commit,
this was deemed to be incorrect, so covert the various tests to use
the volume usage format where the 'usage' is the path to the volume
rather than a user defined name string.
Also, removed the qemuxml2argv-luks-disk-cipher.xml since it was
just a duplicate of qemuxml2argv-luks-disks.xml.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Commit ca10bb040f introduced a new test that fails to build
on at least some architectures:
commandtest.c: In function 'test25':
commandtest.c:1121:5: error: comparison is always true due to
limited range of data type [-Werror=type-limits]
if (rv >= 0) {
^
Change the type of 'rv' from char to int, which is the proper
return type for virCommandExec() anyway.
We can't mock tests on Mingw, which lacks dlopen() and friends;
follow the paradigms used in other mock files of conditionally
compiling nothing when not building for Linux.
Signed-off-by: Eric Blake <eblake@redhat.com>
In an unlikely event of execve() failing, the virCommandExec()
function does not report any error, even though checks that are
at the beginning of the function are verbose when failing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Check whether QEMU supports -device intel-iommu
Note that the presence of this option does not mean that it's
usable because of a bug in earlier QEMU versions, but it's
better than nothing.
https://bugzilla.redhat.com/show_bug.cgi?id=1235580
Commit c9c03ea stopped creating an intermediate file during syntax-check
to save on execution time. It also switched to outputting the whole
incorrectly wrapped file instead of a diff needed to fix it.
Feed the newly wrapped file to diff via a pipe.
Note that fixing it by running test-wrap-argv.pl --in-place or
the unit test with VIR_TEST_REGENERATE_OUTPUT is easier.
Commit 843a70a changed test-wrap-argv.pl to use
/usr/bin/env perl
instead of
/usr/bin/perl
However when called from qemuxml2argvtest with
VIR_TEST_REGENERATE_OUTPUT, PATH is set to '/bin'.
Find the path to perl early in virTestMain, in case we
are going to need it later after we've overridden PATH.
In commit ec5dcf2a and b0b4a35c we have moved qemuhotplugtest's XMLs to
new directories but forgot to fix the Makefile. Add 2 directories in
EXTRA_DIST to fix broken VPATH build. Also remove now unused
qemuhotplugtestdata directory from the Makefile as well as from the
tree.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The libvirtdconftest was previously used to test data type
handling of the libvirtd config file. Now we're using the
typedef APIs, this test case has little value, and is pretty
hard to fixup with deal with the new APIs.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Currently many users of virConf APIs are defining the same
macros for calling virConfValue() and then doing type
checking. To remove this repeated code, add a set of
typesafe accessor methods.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The virconftest is different from all our other tests in that
the C program only tests a single in/out config file pair. It
relies on a shell wrapper to invoke it once for each test
file.
This gets rid of the shell wrapper and makes the C program
actually run over each test file using the normal test pattern.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This way we can safely differentiate what XMLs contain whole domain
definitions and which contain just devices. Thanks to that we can
test the domain XMLs in virschematest again.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This makes the search for related XMLs easier, plus they are not used in
the xml2argv tests anyway. This also makes future patches cleaner.
While on that remove unnecessary '-hotplug' from the filenames.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
In the mock, we have a stub for virNetDevTapCreate(). However,
the mocked version does not exactly as it's native counterpart.
The function receives a string, which is an interface name that
caller would like to have, but it's not guaranteed that they will
get just that one. If they don't, the function free()-s the one
passed and returns the new one. Just like the mocked version. But
what is the mocked version missing is the free().
==1068== 6 bytes in 1 blocks are definitely lost in loss record 9 of 132
==1068== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==1068== by 0xDE13356: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==1068== by 0xAE2333E: virXMLPropString (virxml.c:479)
==1068== by 0xAE45975: virDomainNetDefParseXML (domain_conf.c:9038)
==1068== by 0xAE5C0BB: virDomainDefParseXML (domain_conf.c:16734)
==1068== by 0xAE5EB96: virDomainDefParseNode (domain_conf.c:17444)
==1068== by 0xAE5EA05: virDomainDefParse (domain_conf.c:17391)
==1068== by 0xAE5EA93: virDomainDefParseFile (domain_conf.c:17415)
==1068== by 0x433430: testCompareXMLToArgvFiles (qemuxml2argvtest.c:278)
==1068== by 0x433A18: testCompareXMLToArgvHelper (qemuxml2argvtest.c:414)
==1068== by 0x446ED4: virTestRun (testutils.c:179)
==1068== by 0x43A099: mymain (qemuxml2argvtest.c:1016)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It's just test, but why leak it?
==26971== 20 bytes in 1 blocks are definitely lost in loss record 623 of 704
==26971== at 0x4C29F80: malloc (vg_replace_malloc.c:296)
==26971== by 0xE560447: vasprintf (vasprintf.c:76)
==26971== by 0xAE0DEE2: virVasprintfInternal (virstring.c:480)
==26971== by 0xAE0DFF7: virAsprintfInternal (virstring.c:501)
==26971== by 0x4751F3: qemuProcessPrepareMonitorChr (qemu_process.c:2651)
==26971== by 0x4334B1: testCompareXMLToArgvFiles (qemuxml2argvtest.c:297)
==26971== by 0x4339AC: testCompareXMLToArgvHelper (qemuxml2argvtest.c:413)
==26971== by 0x446E7A: virTestRun (testutils.c:179)
==26971== by 0x445D33: mymain (qemuxml2argvtest.c:2029)
==26971== by 0x44886F: virTestMain (testutils.c:969)
==26971== by 0x445D9B: main (qemuxml2argvtest.c:2036)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Status XML tests were done by prepending a constant string to an
existing XML. With the planned changes the header will depend on data
present in the definition rather than just on the data that was parsed.
The first dynamic element in the header will be the vcpu thread list.
Reuse and rename qemuXML2XMLPreFormatCallback for gathering the relevant
data when checking the active XML parsing and formating and pass the
bitmap to a newly crated header generator.
As the empty bitmap exists, we should also test it. This patch adds
test cases for the procedures 'virBitmapNextSetBit', 'virBitmapLastSetBit',
'virBitmapNextClearBit'.
Tested-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
This is preferrable to -nographic which (in addition to disabling
graphics output) redirects the serial port to stdio and on OpenBIOS
enables the firmware's serial console.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
For type='ethernet' interfaces only.
(This patch had been pushed earlier in
commit 0b4645a7e0, but was reverted in
commit 84d47a3cce because it had been
accidentally pushed during the freeze for release 2.0.0)
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types if needed, and 2) we can retain the info
when set to an invalid interface type all the way through to
validation and report a proper error, rather than just ignoring it
(which is currently what happens for many other type-specific
settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
(This patch had been pushed earlier in
commit fe6a77898a, but was reverted in
commit d658456530 because it had been
accidentally pushed during the freeze for release 2.0.0)
In order to use more common code and set up for a future type, modify the
encryption secret to allow the "usage" attribute or the "uuid" attribute
to define the secret. The "usage" in the case of a volume secret would be
the path to the volume as dictated by the backwards compatibility brought
on by virStorageGenerateQcowEncryption where it set up the usage field as
the vol->target.path and didn't allow someone to provide it. This carries
into virSecretObjListFindByUsageLocked which takes the secret usage attribute
value from from the domain disk definition and compares it against the
usage type from the secret definition. Since none of the code dealing
with qcow/qcow2 encryption secrets uses usage for lookup, it's a mostly
cosmetic change. The real usage comes in a future path where the encryption
is expanded to be a luks volume and the secret will allow definition of
the usage field.
This code will make use of the virSecretLookup{Parse|Format}Secret common code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Add a new secret type known as "passphrase" - it will handle adding the
secret objects that need a passphrase without a specific username.
The format is:
<secret ...>
<uuid>...</uuid>
...
<usage type='passphrase'>
<name>mumblyfratz</name>
</usage>
</secret>
Signed-off-by: John Ferlan <jferlan@redhat.com>
I'm not sure why our code claimed "-boot menu=on" cannot be used in
combination with per-device bootindex, but it was proved wrong about
four years ago by commit 8c952908. Let's always use bootindex when QEMU
supports it.
https://bugzilla.redhat.com/show_bug.cgi?id=1323085
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Verify that SCSI controllers get created automatically when a SCSI disk
is hot-plugged to a domain that doesn't have a matching SCSI controller
defined already.
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Commit cf0568b0af moved a bunch of functions from virNetDev
to the more specific virNetDevIP; however, not all of the
existing uses were moved properly, causing build failures on
FreeBSD.
Complete the transition to the new names and drop the
obsolete declarations from the header file while at it.
This is place as a sub-element of <source>, where other aspects of the
host-side connection to the network device are located (network or
bridge name, udp listen port, etc). It's a bit odd that the interface
we're configuring with this info is itself named in <target dev='x'/>,
but that ship sailed long ago:
<interface type='ethernet'>
<mac address='00:16:3e:0f:ef:8a'/>
<source>
<ip address='192.168.122.12' family='ipv4'
prefix='24' peer='192.168.122.1'/>
<ip address='192.168.122.13' family='ipv4' prefix='24'/>
<route family='ipv4' address='0.0.0.0'
gateway='192.168.122.1'/>
<route family='ipv4' address='192.168.124.0' prefix='24'
gateway='192.168.124.1'/>
</source>
</interface>
In practice, this will likely only be useful for type='ethernet', so
its presence in any other type of interface is currently forbidden in
the generic device Validate function (but it's been put into the
general population of virDomainNetDef rather than the
ethernet-specific union member so that 1) we can more easily add the
capability to other types, and 2) we can retain the info when set to
an invalid interface type all the way through to validation and report
a proper error, rather than just ignoring it (which is currently what
happens for many other type-specific settings).
(NB: The already-existing configuration of IP info for the guest-side
of interfaces is in subelements directly under <interface>, and the
name of the guest-side interface (when configurable) is in <guest
dev='x'/>).
When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).
When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.
In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.
This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.
NB: I decided on this course of action after mentioning the
inconsistency here:
https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html
and getting encouragement do eliminate it in a later IRC discussion
with danpb.
Now that we can include <interface type='ethernet'> in tests, we could
almost test XML that has an <ip> element in an interface. Except that
the test fails when it tries to actually set the IP address for the
interface's tap device. This patch mocks virNetDevSetIPAddress() to
just return success.
These had been declared in conf/device_conf.h, but then used in
util/virnetdev.c, meaning that we had to #include conf/device_conf.h
in virnetdev.c (which we have for a long time said shouldn't be done.
This caused a bigger problem when I tried to #include util/virnetdev.h
in a file in src/conf (which is allowed) - for some reason the
"device_conf.h: File not found" error.
The solution is to move the data types and functions used in util
sources from conf to util. Some names were adjusted during the move
("virInterface" --> "virNetDevIf", and "VIR_INTERFACE" -->
"VIR_NETDEV_IF")
Some Intel processor families (e.g. the Intel Xeon processor E5 v3
family) introduced some PQos (Platform Qos) features, including CMT
(Cache Monitoring technology) and MBM (Memory Bandwidth Monitoring),
to monitor or control shared resource. This patch add them into x86
part of cpu_map.xml to be used for applications based on libvirt to
get cpu capabilities. For example, Nova in OpenStack schedules guests
based on the CPU features that the host has.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
The VIR_STORAGE_POOL_EVENT_REFRESHED constant does not
reflect any change in the lifecycle of the storage pool.
It should thus not be part of the storage pool lifecycle
event set, but rather be a top level event in its own
right. Thus we introduce VIR_STORAGE_POOL_EVENT_ID_REFRESH
to replace it.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In order to read 16 bits of data in the native format and convert add
the 16 bit macros to match existing 32 and 64 bit code.
Signed-off-by: John Ferlan <jferlan@redhat.com>
This partially reverts commit 9b45c9f049.
It changed the default format of socket address from the one SASL
requires, but did not adjust all the callers.
It also removed the test coverage for it.
Revert most of the changes except the virSocketAddrFormatFull support
for URI-formatted strings.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1345743 while
reverting the format used by virt-admin's client-info command from
the URI one to the SASL one.
https://bugzilla.redhat.com/show_bug.cgi?id=1345743
In cases where we expect parse failure of the test input file the
testsuite can't differentiate if the parser failed when parsing or when
opening the file. Add a call to virFileExists and error out on missing
input files.
Missing output files are partially expected when regenerating test
output.
Move the enum into a new src/util/virsecret.h, rename it to be
virSecretLookupType. Add a src/util/virsecret.h in order to perform
a couple of simple operations on the secret XML and virSecretLookupTypeDef
for clearing and copying.
This includes quite a bit of collateral damage, but the goal is to remove
the "virStorage*" and replace with the virSecretLookupType so that it's
easier to to add new lookups that aren't necessarily storage pool related.
Signed-off-by: John Ferlan <jferlan@redhat.com>
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>
Documentation for the "guest-set-vcpus" command describes a proper
algorithm how to set vcpus. This patch makes the following changes:
- state of cpus that has not changed is not updated
- if the command was partially successful the command is re-tried with
the rest of the arguments to get a proper error message
- code is more robust against malicious guest agent
- fix testsuite to the new semantics
Make them work again... The xml2xml had been working, but the xml2argv
were not working. Making the xml2argv work required a few adjustments to
the xml to update to more recent times.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Since we support QEMU 0.12 and later, checking for support of specific flags
added prior to that isn't necessary.
Thus start with the base of having the "-o options" available for the
qemu-img create option and then determine whether we have the compat
option for qcow2 files (which would be necessary up through qemu 2.0
where the default changes to compat 0.11).
Adjust test to no long check for NONE and FLAG options as well was removing
results of tests that would use that option.
Signed-off-by: John Ferlan <jferlan@redhat.com>
This script can already operate on a list of files.
Add a --check parameter to check if multiple files are wrapped
correctly with a single invocation of the script.
We have a list of parameters in @args, that need to be rewrapped
and separated by a space and escaped newline: " \\\n", with the
exception of the last one, which only needs a newline.
Instead of a for cycle, rewrap the individual arguments using map,
and interleave them with escaped newlines by using join.
This tests checks that the first word after SYNOPSIS
in virsh help ${command} output is ${command}.
This was only good to check that the command option structures
are valid, which is now served by 'virsh self-test'.
A new hidden command for virsh that will iterate over
all command groups and commands and print help for every single one.
This involves running vshCmddefOptParse so we can get an error if
one of the command's option structure is invalid.
Since e8ac4a7 this test wastes some CPU cycles by blindly trying to
run almost every virsh command, blindly throwing away the output
and the return value and returning success if 'virsh help' successfully
returned at least one command.
Drop it completely.
This will be used for the caller that needs to specify a separator.
Currently identical to virBitmapParse.
Also change one test case to use the new function.
The '-usb' option doesn't have any effect for aarch64 mach-virt
guests, so the fact that it's currently enabled by default is not
really causing any issue.
However, that might change in the future (although unlikely), and
having it as part of the QEMU command line can cause confusion to
someone looking through the process list.
Avoid it completely, like it's already happening for q35.
Commit 2a58ed0b added support for creating guests with USB
hostdevs. Commit fc21d10 later added support for hotplut of
USB hostdevs. Advertise support for USB hostdevs in the
domcapabilities.
In addition add the appropriate caps for USB support on
domaincapstest when libvirt is built on a Xen with
LIBXL_HAVE_PVUSB. Otherwise domaincapstest would fail i.e.
testing the wrong domain capabilities.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
There has been some progress lately in enabling virtio-pci on
aarch64 guests; however, guest OS support is still spotty at best,
so most guests are going to be using virtio-mmio instead.
Currently, mach-virt guests are closely modeled after q35 guests,
and that includes always adding a dmi-to-pci-bridge that's just
impossible to get rid of. While that's acceptable (if suboptimal)
for q35, where you will always need some kind of PCI device anyway,
mach-virt guests should be allowed to avoid it.
Our current detection code uses just the number of CPU features which
need to be added/removed from the CPU model to fully describe the CPUID
data. The smallest number wins. But this may sometimes generate wrong
results as one can see from the fixed test cases. This patch modifies
the algorithm to prefer the CPU model with matching signature even if
this model results in a longer list of additional features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The CPU model was implemented in QEMU by commit f6f949e929.
The change to i7-5600U is wrong since it's a 5th generation CPU, i.e.,
Broadwell rather than Skylake, but that's just the result of our CPU
detection code (which is fixed by the following commit).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Until now, a Q35 domain (or arm/virt, or any other domain that has a
pcie-root bus) would always have a pci-bridge added, so that there
would be a hotpluggable standard PCI slot available to plug in any PCI
devices that might be added. This patch removes the explicit add,
instead relying on the pci-bridge being auto-added during PCI address
assignment (it will add a pci-bridge if there are no free slots).
This doesn't eliminate the dmi-to-pci-bridge controller that is
explicitly added whether or not a standard PCI slot is required (and
that is almost never used as anything other than a converter between
pcie.0's PCIe slots and standard PCI). That will be done separately.
This option allows or disallows detection of zero-writes if it is set to
"on" or "off", respectively. It can be also set to "unmap" in which
case it will try discarding that part of image based on the value of the
"discard" option.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Commit 11567cf66f introduced an include which will only work when
building with xen (particularly libxl). However, that file is supposed
to be includable from anywhere (as with other testutils* files.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Add support to xenconfig for conversion of xl.cfg(5) bios config
to/from libvirt domXml <loader> config. SeaBIOS is the default
for HVM guests using upstream QEMU. ROMBIOS is the default when
using the old qemu-dm. This patch allows specifying OVMF as an
alternate firmware.
Example xl.cfg:
bios = "ovmf"
Example domXML:
<os>
...
<loader readonly='yes' type='pflash'>/usr/lib/xen/boot/ovmf.bin</loader>
</os>
Note that currently Xen does not support a separate nvram for
non-volatile variables.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.
To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
In 3704b9003 ("tests: Add CPU detection tests"), a macro called
DO_TEST_CPUID_JSON is added. But it took only two arguments when QEMU
or YAJL is not set.
Fix it by adding a third argument. Shouldn't have any effect because
that macro compiles to nothing.
Signed-off-by: Wei Liu <wei.liu2@citrix.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>
Move all APIs with a virHostCPU name prefix out into new
util/virhostcpu.h & util/virhostcpu.c files
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
In preparation for moving all the CPU related APIs out of
the nodeinfo file, give them a virHostCPU name prefix.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Instead of having platform specific code in nodeGetInfo to
fetch CPU topology, split it all out into a new method
nodeGetCPUInfo.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Nearly all the methods in the nodeinfo file are given a
'const char *sysfs_prefix' parameter to override the
default sysfs path (/sys/devices/system). Every single
caller passes in NULL for this, except one use in the
unit tests. Furthermore this parameter is totally
Linux-specific, when the APIs are intended to be cross
platform portable.
This removes the sysfs_prefix parameter and instead gives
a new method linuxNodeInfoSetSysFSSystemPath for use by
the test suite.
For two of the methods this hardcodes use of the constant
SYSFS_SYSTEM_PATH, since the test suite does not need to
override the path for thos methods.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This new listen type is currently supported only by spice graphics.
It's introduced to make it easier and clearer specify to not listen
anywhere in order to start a guest with OpenGL support.
The old way to do this was set spice graphics autoport='no' and don't
specify any ports. The new way is to use <listen type='none'/>. In
order to be able to migrate to old libvirt the migratable XML will be
generated without the listen element and with autoport='no'. Also the
old configuration will be automatically converted to the this listen
type.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
VNC graphics already supports sockets but only via 'socket' attribute.
This patch coverts that attribute into listen type 'socket'.
For backward compatibility we need to handle listen type 'socket' and 'socket'
attribute properly to support old XMLs and new XMLs. If both are provided they
have to match, if only one of them is provided we need to be able to parse that
configuration too.
To not break migration back to old libvirt if the socket is provided by user we
need to generate migratable XML without the listen element and use only 'socket'
attribute.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Since commit 7140807917, qemu agent
channel cannot be plugged in because we won't generate its path
automatically. Let's not only fix that, but also add tests for it so
next time it's checked for.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1322210
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Until now, the only hot thing in this test was the name. That's because
we set the id to '-1' before every test. With this change, we test the
hotplug on live domains as the name suggests and as it should be.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The actual CPU model in the data files is Penryn which makes the file
name look rather strange. Well, one of them contains Nehalem, but that's
a bug which will be fixed soon.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
As a side effect this changes the order of CPU features in XMLs
generated by libvirt, but that's not a big deal since the order there is
insignificant.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. This patch prepares the x86 CPU
driver code for the new 'ecx_in' CPUID parameter.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
So far we only test CPUID -> CPU def conversion on artificial CPUID data
computed from another CPU def. This patch adds the infrastructure to
test this conversion on real data gathered from a host CPU and two
helper scripts for adding new test data:
- cpu-gather.sh runs cpuid tool and qemu-system-x86_64 to get CPUID data
from the host CPU; this is what users can be asked to run if they run
into an issue with host CPU detection in libvirt
- cpu-parse.sh takes the data generated by cpu-gather.sh and creates
data files for CPU detection tests
The CPUID data queried from QEMU will eventually switch to the format
used by query-host-cpu QMP command once QEMU implements it. Until then
we just spawn QEMU with -cpu host and query the guest CPU in QOM. They
should both provide the same CPUID results, but query-host-cpu does not
require any guest CPU to be created by QEMU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The current version uses the first JSON reply from the file as monitor
greeting. With the new parameter the caller can now request a simple
test monitor to be created, which uses an artificial greeting and uses
all JSON strings from the file as regular replies.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
It's a convenient wrapper around qemuMonitorTestNew which feeds the test
monitor with QMP replies from a specified file.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
CPUID instruction normally takes its parameter from EAX, but sometimes
ECX is used as an additional parameter. Let's rename 'function' to
'eax_in' in preparation for adding 'ecx_in'.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When computing CPU data for a given guest CPU we should set CPUID vendor
bits appropriately so that we don't lose the vendor when transforming
CPU data back to XML description.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Extend the virNetTLSContextNew* constructors to allow
the TLS priority string to be passed in, overriding the
compile time default.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We need to use the gnutls_priority_set_direct method which
was not introduced until 2.1.7, so bump version to 2.2.0
which is the first stable release with it included. This
release dates from Dec 2007 so it is reasonable to ditch
support for the 1.x.x series for gnutls releases entirely.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We use libxml2 APIs in the test (e.g. xmlFreeDoc) but not link
with -lxml2 which can cause problems:
/usr/bin/ld: virschematest.o: undefined reference to symbol 'xmlFreeDoc@@LIBXML2_2.4.30'
//usr/lib/x86_64-linux-gnu/libxml2.so.2: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:4702: recipe for target 'virschematest' failed
Reported-by: Katerina Koukiou <k.koukiou@googlemail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
So the story goes like this. The testSchemaDirs() function is
called with: a) the schema file, b) list of the directories that
contains XMLs documents that should be checked against the schema
file from a). However, the directories in the list are really
just their names and it's up to testSchemaDirs to construct the
absolute path and call testSchemaDir() which then does the actual
validation. The absolute path is constructed, but never actually
used (maybe due to a typo). Thus a VPATH build is broken.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Since it will not be called from outside of conf we can unexport it too
if we move it to the appropriate place.
Test suite change is necessary since the error will be reported sooner
now.
Historically, we added heads=1 to videos, but for example for qxl, we
did not reflect that on the command line.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283207
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Move the module from qemu_command.c to a new module virqemu.c and
rename the API to virQEMUBuildObjectCommandline.
This API will then be shareable with qemu-img and the need to build
a security object for luks support.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Pulls in several portability fixes, including the fact that gnulib
now only works on platforms with two's complement signed integers.
Also makes for a smaller delta on the next update (we are waiting
on a license change to unsetenv for the sake of mingw).
* .gnulib: Update to latest.
* bootstrap: Resync from upstream.
* tests/virstringtest.c: Drop use of obsolete probes of integer
properties.
Signed-off-by: Eric Blake <eblake@redhat.com>
When a SCSI controller is present, ESX adds several pciBridge devices
to vmx file. This fixes an error message where it refuses to create VM
due to not enough PCI devices available. This applies only to virtualHW
version >= 7.
Hand-entering indexes for 20 PCI controllers is not as tedious as
manually determining and entering their PCI addresses, but it's still
annoying, and the algorithm for determining the proper index is
incredibly simple (in all cases except one) - just pick the lowest
unused index.
The one exception is USB2 controllers because multiple controllers in
the same group have the same index. For these we look to see if 1) the
most recently added USB controller is also a USB2 controller, and 2)
the group *that* controller belongs to doesn't yet have a controller
of the exact model we're just now adding - if both are true, the new
controller gets the same index, but in all other cases we just assign
the lowest unused index.
With this patch in place and combined with the automatic PCI address
assignment, we can define a PCIe switch with several ports like this:
<controller type='pci' model='pcie-root-port'/>
<controller type='pci' model='pcie-switch-upstream-port'/>
<controller type='pci' model='pcie-switch-downstream-port'/>
<controller type='pci' model='pcie-switch-downstream-port'/>
<controller type='pci' model='pcie-switch-downstream-port'/>
<controller type='pci' model='pcie-switch-downstream-port'/>
<controller type='pci' model='pcie-switch-downstream-port'/>
...
These will each get a unique index, and PCI addresses that connect
them together appropriately with no pesky numbers required.
<os>
<acpi>
<table type="slic">/path/to/acpi/table/file</table>
</acpi>
</os>
will result in:
-acpitable sig=SLIC,file=/path/to/acpi/table/file
This option was introduced by QEMU commit 8a92ea2 in 2009.
https://bugzilla.redhat.com/show_bug.cgi?id=1327537
Add a new element to <domain> XML:
<os>
<acpi>
<table type="slic">/path/to/acpi/table/file</table>
</acpi>
</os>
To supply a path to a SLIC (Software Licensing) ACPI
table blob.
https://bugzilla.redhat.com/show_bug.cgi?id=1327537
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.
This is identical to type='bridge', but without the "connect to a
bridge" part, so it can be handled by using the same functions (and
often even the same cases in switch statements), after renaming
virLXCProcessSetupInterfaceBridged() to virLXCProcessInterfaceTap()
and enhancing it to skip bridge-related items when brname == NULL.
To be truly useful, we need to support setting the ip address on the
host side veth as well as guest side veth (already supported for
type='bridge'), as well as setting the peer address for both.
The <script> element (supported by type='ethernet' in qemu) isn't
supported in this patch. An error is logged at domain start time if it
is encountered. This may be changed in a later patch.
Test disk-drive-network-rbd-auth-AES depends on existence of
gnutls_cipher_encrypt() function which was introduced in gnutls 2.10.0.
On systems without this function we should skip this test.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
This test requests a read-only virtual FAT drive on the IDE bus.
Read-only IDE drives are unsupported, but libvirt only displays
the error if it has the QEMU_CAPS_DRIVE_READONLY capability.
Read-write FAT drives are also unsupported.
Rather than only assigning a PCI address when no address is given at
all, also do it when the config says that the address type is 'pci',
but it gives no address (virDeviceInfoPCIAddressWanted()).
There are also several places after parsing but prior to address
assignment where code previously expected that any info with address
type='pci' would have a *valid* PCI address, which isn't always the
case - now we check not only for type='pci', but also for a valid
address (virDeviceInfoPCIAddressPresent()).
The test case added in this patch was directly copied from Cole's patch titled:
qemu: Wire up address type=pci auto_allocate
I've encountered this error while trying out this feature on some
systems:
$ VIR_TEST_FILE_ACCESS=1 ./virhashtest \
libvirt.git/tests/.libs/lt-virhashtest: \
symbol lookup error: libvirt.git/tests/.libs/virtestmock.so: \
undefined symbol: libvirt_event_poll_purge_timeout_semaphore
Problem is, linking just libvirt_utils to virmock.la is not
enough. We might need to link libvirt_probes.lo too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
There is a lot to explain, but I try to make it as short as
possible. I'd start by pasting some parts of sys/stat.h:
extern int stat (const char *__restrict __file,
struct stat *__restrict __buf) __THROW __nonnull ((1, 2));
extern int __REDIRECT_NTH (stat, (const char *__restrict __file,
struct stat *__restrict __buf), stat64)
__nonnull ((1, 2));
__extern_inline int
__NTH (stat (const char *__path, struct stat *__statbuf))
{
return __xstat (_STAT_VER, __path, __statbuf);
}
Only one of these is effective at once, due to some usage of
the mess we are dealing with in here. So, basically, while
compiling or linking stat() in our code can be transformed into
some other func. Or a dragon.
Now, if you read stat(2) manpage, esp. "C library/kernel
differences" section, you'll learn that glibc uses some tricks
for older applications to work. I haven't gotten around actual
code that does this, but based on my observations, if 'stat'
symbol is found, glibc assumes it's dealing with ancient
application. Unfortunately, it can be just ours stat coming from
our mock. Therefore, calling stat() from a test will end up in
our mock. But since glibc is not exposing the symbol anymore, our
call of real_stat() will SIGSEGV immediately as the pointer to
function is NULL. Therefore, we should expose only those symbols
we know glibc has.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It wasn't as great idea as I thought. Thing around stat() are
more complicated than that. Therefore we need to revert
86d1705a8a plus drop use of the macro as introduced in
later patches.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1182074
If they're available and we need to pass secrets to qemu, then use the
qemu domain secret object in order to pass the secrets for RBD volumes
instead of passing the base64 encoded secret on the command line.
The goal is to make AES secrets the default and have no user interaction
required in order to allow using the AES mechanism. If the mechanism
is not available, then fall back to the current plain mechanism using
a base64 encoded secret.
New APIs:
qemu_domain.c:
qemuDomainGetSecretAESAlias:
Generate/return the secret object alias for an AES Secret Info type.
This will be called from qemuDomainSecretAESSetup.
qemuDomainSecretAESSetup: (private)
This API handles the details of the generation of the AES secret
and saves the pieces that need to be passed to qemu in order for
the secret to be decrypted. The encrypted secret based upon the
domain master key, an initialization vector (16 byte random value),
and the stored secret. Finally, the requirement from qemu is the IV
and encrypted secret are to be base64 encoded.
qemu_command.c:
qemuBuildSecretInfoProps: (private)
Generate/return a JSON properties object for the AES secret to
be used by both the command building and eventually the hotplug
code in order to add the secret object. Code was designed so that
in the future perhaps hotplug could use it if it made sense.
qemuBuildObjectSecretCommandLine (private)
Generate and add to the command line the -object secret for the
secret. This will be required for the subsequent RBD reference
to the object.
qemuBuildDiskSecinfoCommandLine (private)
Handle adding the AES secret object.
Adjustments:
qemu_domain.c:
The qemuDomainSecretSetup was altered to call either the AES or Plain
Setup functions based upon whether AES secrets are possible (we have
the encryption API) or not, we have secrets, and of course if the
protocol source is RBD.
qemu_command.c:
Adjust the qemuBuildRBDSecinfoURI API's in order to generate the
specific command options for an AES secret, such as:
-object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted,
format=base64
-drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\
mon_host=mon1.example.org\:6321,password-secret=$alias,...
where the 'id=' value is the secret object alias generated by
concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey'
is the master key shared with qemu, and the -drive syntax will
reference that alias as the 'password-secret'. For the -drive
syntax, the 'id=myname' is kept to define the username, while the
'key=$base64 encoded secret' is removed.
While according to the syntax described for qemu commit '60390a21'
or as seen in the email archive:
https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html
it is possible to pass a plaintext password via a file, the qemu
commit 'ac1d8878' describes the more feature rich 'keyid=' option
based upon the shared masterKey.
Add tests for checking/comparing output.
NB: For hotplug, since the hotplug code doesn't add command line
arguments, passing the encoded secret directly to the monitor
will suffice.
Introduce virCryptoHaveCipher and virCryptoEncryptData to handle
performing encryption.
virCryptoHaveCipher:
Boolean function to determine whether the requested cipher algorithm
is available. It's expected this API will be called prior to
virCryptoEncryptdata. It will return true/false.
virCryptoEncryptData:
Based on the requested cipher type, call the specific encryption
API to encrypt the data.
Currently the only algorithm support is the AES 256 CBC encryption.
Adjust tests for the API's
Create a mock for virRandomBytes to generate a not so random value.
This should be usable by other tests that need a not so random number
to be generated by including the virrandommock at preload.
The "random number" generated is based upon the size of the expected
stream of bytes being returned where each byte in the result gets
the index of the array - hence a 4 byte array returns 0x00010203.
According to QEMU docs, the '-m' option for specifying RAM is by default
in MiB, and a suffix of "M" or "G" may be passed for values in MiB and
GiB respectively. This commit adds support and a test for the same.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=812295
Signed-off-by: Nishith Shah <nishithshah.2211@gmail.com>
Commit 55320c23 introduced a new test for VNC to test if
vnc_auto_unix_socket is set in qemu.conf, but forget to enable it in
qemuxml2argvtest.c.
This patch also moves the code in qemuxml2xmltest.c next to other VNC
tests and refactor the test so we also check the case for parsing active
XML.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There's no reason for keeping the features in a linked list. Especially
when we know upfront the total number of features we are loading.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
While introducing virtestmock.la, I've forgotten to add '\' at
the end of one line leaving our Makefile.am mangled. Fortunately,
the only thing that comes after is '$(NULL)' so nothing is
terribly broken.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
All qemu versions we support have QEMU_CAPS_DEVICE, so checking
for it is redundant. Remove the usage.
The code diff isn't clear, but all that code is just inindented
with no other change.
Test cases that hit qemuDomainAssignAddresses but don't have
infrastructure for specifying qemuCaps values see lots of
churn, since now PCI addresses are in the XML output.
Upcoming patches are going to make the disk portion of these
test cases fail. In order to make it work, we would need to
extend the qemuargv2xml test infrastructure to handle qemuCaps.
This is worthwhile to do at some point but isn't critical.
Instead just drop the offending portion, which isn't even the
target of the test cases anyways
This wires up qemuDomainAssignAddresses into the new
virDomainDefAssignAddressesCallback, so it's always triggered
via virDomainDefPostParse. We are essentially doing this already
with open coded calls sprinkled about.
qemu argv parse output changes slightly since previously it wasn't
hitting qemuDomainAssignAddresses.
https://bugzilla.redhat.com/show_bug.cgi?id=1331552
Instead of disabling auto-login of all scsi targets (even those
that do not "belong" to libvirt), use iscsiadm's "--op nonpersistent"
during discovery of iSCSI targets (e.g. "iscsiadm --mode discovery
--type sendtargets") in order to avoid the node database being altered
which led to the need for the "large hammer" approach taken by
commit id '3c12b654'.
This commit removes the virISCSITargetAutologin adjustment (eg. the setting
of node.startup to "manual"). The iscsiadm command has supported this mode
of operation as of commit id 'ad873767' to open-iscsi.
The only case where the hardware capabilities influence the result
is when no <gic/> element was provided.
The test programs now ensure both that the correct GIC version is
picked in that case, and that hardware capabilities are not taken
into account when the user has already picked a GIC version.
Now that we choose the GIC version based on hardware features when
no <gic/> element has been provided, we need a way to fake the GIC
capabilities of the host.
Update the qemuxml2argv and qemuxml2xml tests to allow this.
We support omitting listen attribute of graphics element so we should
also support omitting address attribute of listen element. This patch
also updates libvirt to always add a listen element into domain XML
except for VNC graphics if socket attribute is specified.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
If socket attribute is present we start VNC that listens only on that
unix socket. This makes the parser behave the same way as we actually
use the socket attribute.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The only QEMU versions that don't have such capability are <0.12,
which we no longer support anyway.
Additionally, this solves the issue of some QEMU binaries being
reported as not having such capability just because they lacked
the {kvm-}pci-assign QMP object.
For a few cases where we handle secret information it's good to clear
the buffers containing sensitive data before freeing them.
Introduce VIR_DISPOSE, VIR_DISPOSE_N and VIR_DISPOSE_STRING that allow
simple clearing fo the buffers holding sensitive information on cleanup
paths.
When -cpu host is supported by a QEMU binary, a user can use
<cpu mode='host-passthrough'/> in domain XML even when libvirtd failed
to find a matching model for the host CPU. Let's make it obvious by
advertising <cpuselection/> guest capability whenever -cpu host is
supported.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This script will check output generated by virtestmock against a
white list. All non matching records found are printed out. So
far, the white list is rather sparse at the moment.
This test should be ran only after all other tests finished, and
should cleanup the temporary file before their execution. Because
I'm unable to reflect these requirements in Makefile.am
correctly, I've introduced new target 'check-access' under which
this test is available.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
All the accesses to files outside our build or source directories
are now identified and appended into a file for later processing.
The location of the file that contains all the records can be
controlled via VIR_TEST_FILE_ACCESS env variable and defaults to
abs_builddir "/test_file_access.txt".
The script that will process the access file is to be added in
next commit.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The intent is that this library is going to be called every time
to check if we are not touching anything outside srcdir or
builddir.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
There is some magic going on when it comes to stat() or lstat().
Basically, stat() can either be a regular function, an inline
function that calls __xstat(_STAT_VER, ...) or a macro that does
the same as the inline func. Don't ask why is that, just read the
documentation in sys/stat.h and make sure you have a bucket next
to you. Anyway, currently there will not be both stat and __xstat
symbols at the same time, as one of them gets overwritten to the
other one during compilation. But this is not true anymore once
we start chaining our mocking libraries. Therefore we need a
wrapper that calls desired function from glibc.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Some of the test configuration files in tests/xlconfigdata
use the old qemu-dm as the emulator. Many of the configuration
features tested (spice, rbd, multi-usb) are not even usable with
the old qemu. Change these files to use the new qemu-xen (also
known as qemu upstream) emulator.
Note: This change fixes xlconfigtest failures when the old
qemu is actually installed on the system. During device post
parse, the libxl driver attempts to invoke the emulator to
determine if it is the old or new qemu so it can properly set
video RAM defaults. With the old qemu installed, the default
video RAM was set differently than the expected value.
Changing all the test data files to use qemu-xen ensures
predictable results wrt default video RAM size.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
libvirt may automatically add a pci-root or pcie-root controller to a
domain, depending on the arch/machinetype, and it hopefully always
makes the right decision about which to add (since in all cases these
controllers are an implicit part of the virtual machine).
But it's always possible that someone will create a config that
explicitly supplies the wrong type of PCI controller for the selected
machinetype. In the past that would lead to an error later when
libvirt was trying to assign addresses to other devices, for example:
XML error: PCI bus is not compatible with the device at
0000:00:02.0. Device requires a PCI Express slot, which is not
provided by bus 0000:00
(that's the error message that appears if you replace the pcie-root
controller in a Q35 domain with a pci-root controller).
This patch adds a check at the same place that the implicit
controllers are added (to ensure that the same logic is used to check
which type of pci root is correct). If a pci controller with index='0'
is already present, we verify that it is of the model that we would
have otherwise added automatically; if not, an error is logged:
The PCI controller with index='0' must be " model='pcie-root' for
this machine type, " but model='pci-root' was found instead.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1004602
Our tests should use either VIRT_TEST_MAIN() or
VIRT_TEST_MAIN_PRELOAD() macros which create main() function and
call the passed callback subsequently. This is important because
the wrapper which calls the callback eventually does important
stuff like setting logging based on env variables and such.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Requires adding the plumbing for <device><video>
The value is <enum name='modelType'> to match the associated domain
XML of <video><model type='XXX'/>
Wire it up for qemu too
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>
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>
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>
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...
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.
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>
Our socket address format is in a rather non-standard format and that is
because sasl library requires the IP address and service to be delimited by a
semicolon. The string form is a completely internal matter, however once the
admin interfaces to retrieve client identity information are merged, we should
return the socket address string in a common format, e.g. format defined by
URI rfc-3986, i.e. the IP address and service are delimited by a colon and
in case of an IPv6 address, square brackets are added:
Examples:
127.0.0.1:1234
[::1]:1234
This patch changes our default format to the one described above, while adding
separate methods to request the non-standard SASL format using semicolon as a
delimiter.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This adds a ports= attribute to usb controller XML, like
<controller type='usb' model='nec-xhci' ports='8'/>
This maps to:
qemu -device nec-usb-xhci,p2=8,p3=8
Meaning, 8 ports that support both usb2 and usb3 devices. Gerd
suggested to just expose them as one knob.
https://bugzilla.redhat.com/show_bug.cgi?id=1271408
Besides ID, libvirt should provide several parameters to help the user
distinguish two clients from each other. One of them is the connection
timestamp. This patch also adds a testcase for proper JSON formatting of the
new attribute too (proper formatting of older clients that did not support
this attribute yet is included in the existing tests) - in order to
testGenerateJSON to work, a mock of time_t time(time_t *timer) needed to be
created.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Admin API needs a way of addressing specific clients. Unlike servers, which we
are happy to address by names both because its name reflects its purpose (to
some extent) and we only have two of them (so far), naming clients doesn't make
any sense, since a) each client is an anonymous, i.e. not recognized after a
disconnect followed by a reconnect, b) we can't predict what kind of requests
it's going to send to daemon, and c) the are loads of them comming and going,
so the only viable option is to use an ID which is of a reasonably wide data
type.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Trying to define a domain name containing an embedded '/'
will immediately fail when trying to write the XML to disk for
our stateful drivers. This patch explicitly rejects names
containing a '/', and provides an xmlopt feature for drivers
to avoid this validation check, which is enabled in every
non-stateful driver that already has xmlopt handling wired up.
(Technically this could reject a previously accepted vmname like
'/foo', however at least for the qemu driver that falls over
later when starting qemu)
https://bugzilla.redhat.com/show_bug.cgi?id=639923
We were lacking tests that are checking for the completeness of our
nodedev XMLs and also whether we output properly formatted ones. This
patch adds parsing for the capability elements inside the <capability
type='pci'> element. Also bunch of tests are added to show everything
works properly.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
There were few things done in the nodedev code but we were lacking tests
for it. And because of that we missed that the schema was not updated
either. Fix the schema and add various test files to show the schema
is correct.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Modeled after the qemuDomainDiskPrivatePtr logic, create a privateData
pointer in the _virDomainHostdevDef to allow storage of private data
for a hypervisor in order to at least temporarily store auth/secrets
data for usage during qemuBuildCommandLine.
NB: Since the qemu_parse_command (qemuParseCommandLine) code is not
expecting to restore the auth/secret data, there's no need to add
code to handle this new structure there.
Updated copyrights for modules touched. Some didn't have updates in a
couple years even though changes have been made.
Signed-off-by: John Ferlan <jferlan@redhat.com>
If qemu doesn't support DEVICE_TRAY_MOVED event the code that attempts
to change media would attempt to re-eject the tray even if it wouldn't
be notified when the tray opened. Add a capability bit and skip retrying
for old qemus.
The man page says: "(Re)-Connect to the hypervisor. When the shell is
first started, this is automatically run with the URI parameter
requested by the "-c" option on the command line." However, if you run:
virsh -c 'test://default' 'connect; uri'
the output will not be 'test://default'. That's because the 'connect'
command does not care about any virsh-only related settings and if it is
run without parameters, it connects with @uri == NULL. Not only that
doesn't comply to what the man page describes, but it also doesn't make
sense. It also means you aren't able to reconnect to whatever you are
connected currently.
So let's fix that in both virsh and virt-admin add a test case for it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Similarly to what commit 7140807917 did with some internal paths,
clear vnc socket paths that were generated by us. Having such path in
the definition can cause trouble when restoring the domain. The path is
generated to the per-domain directory that contains the domain ID.
However, that ID will be different upon restoration, so qemu won't be
able to create that socket because the directory will not be prepared.
To be able to migrate to older libvirt, skip formatting the socket path
in migratable XML if it was autogenerated. And mark it as autogenerated
if it already exists and we're parsing live XML.
Best viewed with '-C'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1326270
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Currently we only allow /dev/random and /dev/hwrng as host input
for <rng><backend model='random'/> device. This was added after
various upstream discussions in commit 4932ef45
However this restriction has generated quite a few complaints over
the years, so a new discussion was initiated:
http://www.redhat.com/archives/libvir-list/2016-April/msg00987.html
Several people suggested removing the restriction, and nobody really
spoke up to defend it. So this patch drops the path restriction
entirely
https://bugzilla.redhat.com/show_bug.cgi?id=1074464
This unifies the test scripts to all use the similar pattern added for
schematests in ace4aecd. This gives the following
- Enables running all tests from outside of tests/ dir
- Drops redundant abs_* definitions, which are set by test-lib.sh
- Drops unnecessary srcdir variable which was only used for sourcing
test-lib.sh
Behavior changes:
- srcdir can no longer be overwritten, but I don't know why anyone would
really need to...
- Script VERBOSE setting no longer prints commands executed by test-lib.sh.
if anyone cares I suggest handling this in test-lib.sh which already
has other verbose style handling
These old tests expect to run against a real xen connection via
xend running on the host. Our intentions for the test suite are
that it doesn't require interacting with any specific host resources,
so these don't really belong here.
Store the test list in libvirtd_test_scripts, and use it where
appropriate. This also fixes the fact that we didn't ship
virsh-uriprecedence when libvirtd build is disabled.
$ echo -n 'log_level=1' > ~/.config/libvirt/libvirtd.conf
$ libvirtd --timeout=10
2014-10-10 10:30:56.394+0000: 6626: info : libvirt version: 1.1.3.6, package: 1.fc20 (Fedora Project, 2014-09-08-17:50:42, buildvm-05.phx2.fedoraproject.org)
2014-10-10 10:30:56.394+0000: 6626: error : main:1261 : Can't load config file: configuration file syntax error: /home/rjones/.config/libvirt/libvirtd.conf:1: expecting a value: /home/rjones/.config/libvirt/libvirtd.conf
Rather than try to fix this in the depths of the parser, just catch
the case when a config file doesn't end in a newline, and manually
append a newline to the content before parsing
https://bugzilla.redhat.com/show_bug.cgi?id=1151409
According to the dnsmasq manpage, the netmask for IPv4 address ranges
will be auto-deteremined from the interface dnsmasq is listening on,
but it can't do this for IPv6 for some reason - it instead assumes a
network prefix of 64 for all IPv6 address ranges. If this is
incorrect, dnsmasq will refuse to give out an address to clients,
instead logging this message:
dnsmasq-dhcp[2380]: no address range available for DHCPv6 request via virbr0
The solution is for libvirt to add ",$prefix" to all IPv6 dhcp-range
arguments when building the dnsmasq.conf file.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1033739
Commit a8743c39 removed keepalive_required attribute from daemon, added a test
case for it, but forgot to enable the test itself in virnetdaemontest.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Commit a4746114 renamed virnetservertest to virnetdaemontest to reflect some
refactor changes to virNetServer code (which moved daemon-related parts to
virNetDaemon module). Moving test data from virnetserverdata to
virnetdaemondata was also part of the commit, but the commit failed to clean
half of the files that were copied (rather than moved).
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This an ubuntu/debian packaging convention. At one point it may have
been an actually different binary, but at least as of ubuntu precise
(the oldest supported ubuntu distro, released april 2012) kvm-img is
just a symlink to qemu-img for back compat.
I think it's safe to drop support for it
Commit 3a773c43c8 introduced the testCompareNetXML2XMLResult
enumeration; however, in one instance the result variable was
assigned a value from the very similar testCompareDocXML2XMLResult
enumeration, leading to a build error.
networkxml2xmltest.c:33:42: error:
implicit conversion from enumeration type 'testCompareDomXML2XMLResult'
to different enumeration type 'testCompareNetXML2XMLResult'
[-Werror,-Wenum-conversion]
testCompareNetXML2XMLResult result = TEST_COMPARE_DOM_XML2XML_RESULT_SUCCESS;
~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Use the proper value (TEST_COMPARE_NET_XML2XML_RESULT_SUCCESS) instead.
The struct contains a single boolean field, 'supported':
the meaning of this field is too generic to be limited to
devices only, and in fact it's already being used for
other things like loaders and OSs.
Instead of trying to come up with a more generic name just
get rid of the struct altogether.
Prior to this patch we didn't make any attempt to prevent two entries
in the array of interfaces/PCI devices from pointing to the same
device.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1002423
This is patterned after similar functionality for domain XML tests,
but tries harder to avoid reading non-existent networkxml2xmlout data
file when parse fails.
So in glibc-2.23 sys/sysmacros.h is no longer included from sys/types.h
and we don't build because of the usage of major/minor/makedev macros.
Autoconf already has AC_HEADER_MAJOR macro that check where exactly
these functions/macros are defined, so let's use that.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
While working on the tests for the secret initialization vector, I found
that the existing iSCSI tests were lacking in how they defined the IQN.
Many had IQN's of just 'iqn.1992-01.com.example' for one disk while using
'iqn.1992-01.com.example/1' for the second disk (same for hostdevs - guess
how they were copied/generated).
Typically (and documented this way), IQN's would include be of the form
'iqn.1992-01.com.example:storage/1' indicating an IQN using "storage" for
naming authority specific string and "/1" for the iSCSI LUN.
So modify the input XML's to use the more proper format - this of course
has a ripple effect on the output XML and the args.
Also note that the "%3A" is generated by the virURIFormat/xmlSaveUri
to represent the colon.
Signed-off-by: John Ferlan <jferlan@redhat.com>
virTypedParamsValidate currently uses an index based check to find
duplicate parameters. This check does not work. Consider the following
simple example:
We have only 2 keys
A (multiples allowed)
B (multiples NOT allowed)
We are given the following list of parameters to check:
A
A
B
If you work through the validation loop you will see that our last iteration
through the loop has i=2 and j=1. In this case, i > j and keys[j].value.i will
indicate that multiples are not allowed. Both conditionals are satisfied so
an incorrect error will be given: "parameter '%s' occurs multiple times"
This patch replaces the index based check with code that remembers
the name of the last parameter seen and only triggers the error case if
the current parameter name equals the last one. This works because the
list is sorted and duplicate parameters will be grouped together.
In reality, we hit this bug while using selective block migration to migrate
a guest with 5 disks. 5 was apparently just the right number to push i > j
and hit this bug.
virsh migrate --live guestname --copy-storage-all
--migrate-disks vdb,vdc,vdd,vde,vdf
qemu+ssh://dsthost/system
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Eric Farman <farman@linux.vnet.ibm.com>
This is backed by the qemu device pxb-pcie, which will be available in
qemu 2.6.0.
As with pci-expander-bus (which uses qemu's pxb device), the busNr
attribute and <node> subelement of <target> are used to set the bus_nr
and numa_node options.
During post-parse we validate that the domain's machinetype is
q35-based (since the device shows up for 440fx-based machinetypes, but
is unusable), as well as checking that <node> specifies a node that is
actually configured on the guest.
This controller provides a single PCIe port on a new root. It is
similar to pci-expander-bus, intended to provide a bus that can be
associated with a guest-identifiable NUMA node, but is for
machinetypes with PCIe rather than PCI (e.g. q35-based machinetypes).
Aside from PCIe vs. PCI, the other main difference is that a
pci-expander-bus has a companion pci-bridge that is automatically
attached along with it, but pcie-expander-bus has only a single port,
and that port will only connect to a pcie-root-port, or to a
pcie-switch-upstream-port. In order for the bus to be of any use in
the guest, it must have either a pcie-root-port or a
pcie-switch-upstream-port attached (and one or more
pcie-switch-downstream-ports attached to the
pcie-switch-upstream-port).
The pxb device is a PCIe expander bus that can be added to any
Q35-based machinetype. A single PCIe port (*not* hotpluggable) is
provided; if more than one device is desired, or if hotplug
support is needed, either a pcie-root-port, or some combination of
pcie-switch-upstream-port and pcie-swith-downstream-ports must be
added to it. It can have a NUMA node number associated with it, as
well as a bus number.
This is backed by the qemu device "pxb".
The pxb device always includes a pci-bridge that is at the bus number
of the pxb + 1.
busNr and <node> from the <target> subelement are used to set the
bus_nr and numa_node options for pxb.
During post-parse we validate that the domain's machinetype is
440fx-based (since the pxb device only works on 440fx-based machines),
and <node> also gets a sanity check to assure that the NUMA node
specified for the pxb (if any - it's optional) actually exists on the
guest.
This is a standard PCI root bus (not a bridge) that can be added to a
440fx-based domain. Although it uses a PCI slot, this is *not* how it
is connected into the PCI bus hierarchy, but is only used for
control. Each pci-expander-bus provides 32 slots (0-31) that can
accept hotplug of standard PCI devices.
The usefulness of pci-expander-bus relative to a pci-bridge is that
the NUMA node of the bus can be specified with the <node> subelement
of <target>. This gives guest-side visibility to the NUMA node of
attached devices (presuming that management apps only assign a device
to a bus that has a NUMA node number matching the node number of the
device on the host).
Each pci-expander-bus also has a "busNr" attribute. The expander-bus
itself will take the busNr specified, and all buses that are connected
to this bus (including the pci-bridge that is automatically added to
any expander bus of model "pxb" (see the next commit)) will use
busNr+1, busNr+2, etc, and the pci-root (or the expander-bus with next
lower busNr) will use bus numbers lower than busNr.
The pxb device is a PCI expander bus that can be added to any
440fx-based machinetype. The PCI bus that is created has 32 standard
PCI slots (hotpluggable). It can have a NUMA node number associated
with it, as well as a bus number.
When support for dmi-to-pci-bridge was added, it was assumed that,
just as with the pci-root bus, slot 0 was reserved. This is not the
case - it can be used to connect a device just like any other slot, so
remove the restriction and update the test cases that auto-assign an
address on a dmi-to-pci-bridge.
* Add a test for listen=XXX and <listen address=YYY/> collision error
* Add an explicit test for listen=XXX duplicated to <listen address=XXX/>
We implicitly test it elsewhere but I figure it's better to be explicit,
and this test case can be extended in the future for additional listen
back compat if/when we support <listen type='socket'/> syntax
In qemuHotplugCreateObjects, the ret variable was filled by
the value returned by qemuTestCapsCacheInsert.
If any of the functions after this assignment failed, we would still
return success.
Also adjust testCompareXMLToArgvHelper, where this change is just
cosmetic, because the value was overwritten right away.
Add codes to support creating domain with network defition of assigning
SRIOV VF from a pool.
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
The address assigning code might add new pci bridges.
We need them to have an alias when building the command line.
In real word usage, this is not a problem because all the code
paths already call qemuDomainAssignAddresses. However moving
this call lets us remove one extra call from qemuxml2argvtest.
It is only used for failed address allocation
Since we already have FLAG_EXPECT_FAILURE, use that instead.
Also unify the output to print the whole log buffer instead
of just the last error message.
After removing qemuBuildCommandLineCallbacks, testutilsqemu.h does not
need to include qemu_command.h.
Include just qemu_conf.h here and qemu_domain_address.h in files that
need it.
Essentially revert commit 3a6204c which added these to allow the test
suite to pass without depending on the host system state.
Since commit 4b527c1 we already mock virSCSIDeviceGetSgName, so these
callbacks are useless.
Commit 119cd06 started setting the primary bool for the first
user-specified video even if user omitted the 'primary' attribute.
However this was done before the addition of the implicit device.
This broke startup of transient qemu domains with no <video>:
https://bugzilla.redhat.com/show_bug.cgi?id=1325757
Move this default to virDomainDefPostParseInternal,
after the addition of the implicit video device, to catch the implicit
video as well.
Commit dc98a5bc refactored the code a lot and forget about checking if
listen attribute is specified. This ensures that listen attribute and
first listen element are compared only if both exist.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
After the test and qemu_process refactor now we can benefit from default
listen address for spice and vnc in tests.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Some places already check for "virt-" prefix as well as plain "virt".
virQEMUCapsHasPCIMultiBus did not, resulting in multiple PCI devices
having assigned the same unnumbered "pci" alias.
Add a test for the "virt-2.6" machine type which also omits the
<model type='virtio'/> in <interface>, to check if
qemuDomainDefaultNetModel works too.
https://bugzilla.redhat.com/show_bug.cgi?id=1325085
If the -object secret capability exists, then get the path to the
masterKey file and provide that to qemu. Checking for the existence
of the file before passing to qemu could be done, but causes issues
in mock test environment.
Since the qemuDomainObjPrivate is not available when building the
command line, the qemuBuildHasMasterKey API will have to suffice
as the primary arbiter for whether the capability exists in order
to find/return the path to the master key for usage.
Created the qemuDomainGetMasterKeyAlias API which will be used by
later patches to define the 'keyid' (eg, masterKey) to be used by
other secrets to provide the id to qemu for the master key.
Add a capability bit for the qemu secret object.
Adjust the 2.6.0-1 caps/replies to add the secret object. For the
.replies it's take from the '{"execute":"qom-list-types"}' output.
Commit d77ffb6876 added not only reporting of the PCI header type, but
also parsing of that information. However, because there was no parsing
done for the other sub-PCI capabilities, if there was any other
capability then a valid header type name (like phys_function or
virt_functions) the parsing would fail. This prevented passing node
device XMLs that we generated into our own functions when dealing with,
e.g. with SRIOV cards.
Instead of reworking the whole parsing, just fix this one occurence and
remove a test for it for the time being. Future patches will deal with
the rest.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
* tools/nss/libvirt_nss.[ch]: add BSD-comptabile wrappers and
register via the nss_module_register() interface
* m4/virt-nss.m4: add checks if we're building NSS for FreeBSD
* tools/Makefile.am: handle target library name differences, as
Linux needs libnss_libvirt.so.2 and FreeBSD needs
nss_libvirt.so.1. Also, different syms files have to be used
as Linux needs to export all the methods while FreeBSD
only needs to have nss_module_register()
* tests/nsstest.c, tests/nssmock.c: s/__linux__/NSS/
* tests/nssmock.c: pass int instead of mode_t to va_arg() to please
gcc 4.8
* libvirt_nss_bsd.syms: FreeBSD syms file
In some cases it's impractical to use the regular APIs as the bitmap
size needs to be pre-declared. These new APIs allow to use bitmaps that
self expand.
The new code adds a property to the bitmap to track the allocation of
memory so that VIR_RESIZE_N can be used.
It was too similar to the non-scaled alternative.
before:
error: Numeric value 'abc' for <size> option is malformed or out of range
after:
error: Scaled numeric value 'abc' for <size> option is malformed or out of range
This patch adds new xml element, and so we can have the option of
also having perf events enabled immediately at startup.
Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Message-id: 1459171833-26416-6-git-send-email-qiaowei.ren@intel.com
This patch adds support for "vpindex", "runtime", "synic",
"stimer", and "vendor_id" features available in qemu 2.5+.
- When Hyper-V "vpindex" is on, guest can use MSR HV_X64_MSR_VP_INDEX
to get virtual processor ID.
- Hyper-V "runtime" enlightement feature allows to use MSR
HV_X64_MSR_VP_RUNTIME to get the time the virtual processor consumes
running guest code, as well as the time the hypervisor spends running
code on behalf of that guest.
- Hyper-V "synic" stands for Synthetic Interrupt Controller, which is
lapic extension controlled via MSRs.
- Hyper-V "stimer" switches on Hyper-V SynIC timers MSR's support.
Guest can setup and use fired by host events (SynIC interrupt and
appropriate timer expiration message) as guest clock events
- Hyper-V "reset" allows guest to reset VM.
- Hyper-V "vendor_id" exposes hypervisor vendor id to guest.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
This test was commited 4 years ago, but was never enabled in
storagepoolxml2xmltest.c. This patch reactivates it, conditionnaly on RBD
storage support being enabled
This test failed for two reasons:
* The uuid was missing from the input file
* The output file had the <name> in a different place from the actual output
If the abs_builddir path already is in PATH and it's in the first
position, due to a bug in our code PATH would be cleared out.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Coverity pointed out that getenv("PATH") may return NULL. Well,
we check for that in virFindFileInPath() too. If this happens, we
will pass NULL into strstr(). Ouch.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The variable is dereferenced prior its check for NULL. The check
itself does not make much sense anyway - it's our test, we know
we are not passing NULL.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The test can return positive value even though it should have failed. It just
returns the value parser returned, which should be flipped back to -1 if
something went wrong or the result was unexpected, but it isn't.
After 9c17d665fd the tap device for ethernet network type is
automatically precreated before spawning qemu. Problem is, the
qemuxml2argvtest wasn't updated and thus is failing. Because of
all the APIs that new code is calling, I had to mock a lot. Also,
since the tap FDs are labeled separately from the rest of the
devices/files I had to enable NOP security driver for the test
too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When constructing SCSI hostdev command line for qemu, the
/sys/bus/scsi/devices/... dir is scanned. Unfortunately, even in
the tests. This is needed to determine the name of SCSI device to
passthrough to qemu, because in the domain XML we were given its
address instead. Anyway, we should not be touching live system
data in our test suite as it produced unpredictable results. The
test is regressing from 1e9a083742 on.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Ensure the code behaves properly even for situations that were not
being considered before, such as simply detaching devices from the
host without attaching them to a guest and attaching devices as
managed even though they had already been manually detached from
the host.
Update testutilsqemu to overwrite libDir and channelTargetDir and set
private paths using domain's privateData. This changes is required for
following patch.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Move all code that checks host and domain. Do not check host if we use
VIR_QEMU_PROCESS_START_PRETEND flag.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Problem is that in the test any status file matching
tests/nssdata/*.status is loaded as it contains IP addresses that
are parsed. However, there's no order specified in which the
files are loaded. Therefore on different systems the order may be
different. This is then producing an unexpected results.
Instead of defining an order in which the files are loaded, make
the code that checks for missing IP addresses (or redundant ones)
cope with unordered list of addresses. The reasoning behind is
that the code doing the parsing is used in real NSS module where
we don't care for ordering.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
hap is enabled by default in xm and xl config and usually only
specified when it is desirable to disable hap (hap = 0). Change
the xm,xl <-> xml converter to behave similarly. I.e. only
produce 'hap = 0' when <hap state='off'/> and vice versa.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
This allows setting the address in host and/or network order and makes
the naming consistent. Now you don't need to call [hn]to[nh]l()
functions as that is taken care of by these functions. Also, now
the *NetOrder take the address in network order, the other functions in
host order so the naming and usage is consistent. Some places were
having the address in network order and calling ntohl() just so the
original function can call htonl() again. This makes it nicer to read.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
If a <graphics type='spice'> has no port nor tlsPort set, the generated
QEMU command line will contain -spice port=0.
This is later going to be ignored by spice-server, but it's better not
to add it at all in this situation.
As an empty -spice is not allowed, we still need to append port=0 if we
did not add any other argument.
Even if nss is disabled, the build system tries to build some
targets like libnss_libvirt_impl.la and nsstest. Hide those
under the "if WITH_NSS" block like the rest of NSS plugin bits.
If we expose this information, which is one byte in every PCI config
file, we let all mgmt apps know whether the device itself is an endpoint
or not so it's easier for them to decide whether such device can be
passed through into a VM (endpoint) or not (*-bridge).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1317531
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The only purpose of this test is to catch possible linking
problems with libnss_libvirt.so.2.
One of the problems I faced was that the NSS plugin was unloaded
immediately after it got loaded and the name resolution process
continued with next configured option. Without any error. It was
very hard to debug why until I created this simple test and found
out immediately that there were some symbols missing. The reason
why problem was not caught in nsstest is that in the test we want
to use all the fancy stuff and therefore link it with libvirt.la.
So even if there's a symbol missing in the NSS plugin it will be
found in the libvirt.la.
But even after I resolved the issue we still need this test
because files the NSS plugin is built from are still live (mostly
those under utils/ dir). So as they change new symbol might be
required which would render the NSS plugin unusable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The implementation is pretty straightforward. Moreover, because
of the nature of things, gethostbyname_r and gethostbyname2_r can
be implemented at the same time too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
None of the existing domXML configs under tests/* specify a
default cache mode since default generally means "use the
hypervisor default" and is left unset by the various hypervisor
drivers. Add a config to tests/domainschemadata that specifies
cache='default'.
Currently we spawn couple of binaries in our test suite.
Moreover, we provide some spoofed versions of system binaries
hoping that those will be executed instead of the system ones.
For instance, for testing SSH socket we have written our own ssh
binary for producing predictable results. We certainly don't want
to execute the system ssh binary.
However, in order to prefer our binaries over system ones, we
need to set PATH environment variable. But this is done only at
the Makefile level. So if anybody runs a test by hand that
expects our spoofed binary, the test ends up executing real
system binaries. This is not good. In fact, it's terribly wrong.
The fix lies in a small trick - putting our build directory at
the beginning of the PATH environment variable in each test.
Hopefully, since every test has this VIRT_TEST_MAIN* wrapper, we
can fix this at a single place.
Moreover, while this removes setting PATH for our tests written
in bash, it's safe as we are not calling anything ours that would
require PATH change there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
We include the file in plenty of places. This is mostly due to
historical reasons. The only place that needs something from the
header file is storage_backend_fs which opens _PATH_MOUNTED. But
it gets the file included indirectly via mntent.h. At no other
place in our code we need _PATH_.*. Drop the include and
configure check then.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Patch adds a generic DO_TEST_FULL macro, some PASS/FAIL macros to better
visually distinguish tests that should fail and tests that should pass. Also,
some cosmetic changes like renames and direct call to fprintf is replaced with
our VIR_TEST_DEBUG macro, as using testutils should be our preferred way of
reporting errors in tests.
Since servers know their name, there is no need to supply such
information twice. Also defeats inconsistencies.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
At first I did not want to do this, but after trying to implement some
newer feaures in the admin API I realized we need that to make our lives
easier. On the other hand they are not saved redundantly and the
virNetServer objects are still kept in a hash table.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
When debug-threads is enabled, individual threads are given a separate
name (on Linux)
Fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1140121
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
QEMU (somewhere around 2.0) added a new sub-option to the -name flag
-name debug-threads=on.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
If use of virtlogd is enabled, then use it for backing the
character device log files too. This avoids the possibility
of a guest denial of service by writing too much data to
the log file.
Honour the <log file='...'/> element in chardevs to output
data to a file. This requires QEMU >= 2.6
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The 'actualCount' variable, formerly just 'count', is only used
internally by the macro, so it's better to move its declaration
inside the macro as well: this way, it doesn't have to be declared
by every single user.
The new name is less generic to make clashes less likely.
When checking the number of devices added to a device list, use the
nhostdevs variable instead of its value, so that the test can keep
working even if more hostdevs are added.
This attribute is used to extend secondary PCI bar and expose it to the
guest as 64bit memory. It works like this: attribute vram is there to
set size of secondary PCI bar and guest sees it as 32bit memory,
attribute vram64 can extend this secondary PCI bar. If both attributes
are used, guest sees two memory bars, both address the same memory, with
the difference that the 32bit bar can address only the first part of the
whole memory.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1260749
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We always place primary video device at first place, to make it easier
to create a qemu command or format an xml, but we should also set the
primary boolean for primary video device to 'true'.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
