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=1355857Signed-off-by: NJiri 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: NJiri Denemark <jdenemar@redhat.com>

As of (v2.7.0-rc1-52-g42e0d60)

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: NMichal 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: NMichal 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: NMichal Privoznik <mprivozn@redhat.com>

All these configurations are already covered for qemuxml2argv,
but there were no equivalent tests for qemuxml2xml.

Now that DO_TEST() can be passed capabilities, there is little
need to use DO_TEST_FULL() instead of DO_TEST().

This will allow us to remove most DO_TEST_FULL() usages. For the
time being, just add the extra argument to all DO_TEST() calls.

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.

Instead of testing it twice using WHEN_ACTIVE and WHEN_INACTIVE
separately, just use WHEN_BOTH.

The test case uses DO_TEST_PARSE_FLAGS_ERROR(), but doesn't
pass any parse flag. Use DO_TEST_PARSE_ERROR() instead.

DO_TEST_FAILURE() doesn't take a GIC version, but the GIC flag
was passed anyway. Get rid of all such occurrences.

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: NMichal Privoznik <mprivozn@redhat.com>

Use a name that contains the command used to get the information.

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 'b65dafa8' 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 '55ecdae0') 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.

Also includes unittests for node device lifecycle events API

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: NChunyan 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 318ebb36
  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: NDaniel 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: NPeter 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.

Along with the legacy URI based syntax add support for the brand-new
fully object based syntax.

http(s), ftp(s) and tftp use URIs for volume definitions in the JSON
pseudo protocol so it's pretty straightforward to add support for them.

JSON pseudo protocol for qemu allows to explicitly specify devices.
Add convertor to the internal type.

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.

The function would generate a leading comma. Let the callers properly
add commas by formatting the commas at the end and trimming the trailing
one.

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.

Move the iterator of objects to the recursive function so that nested
objects are supported by flattening the structure with '.' delimiters.

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.

Purely cosmetic change to be consistent with the other names.
Signed-off-by: NHenning Schild <henning.schild@siemens.com>

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.