This reverts commit 6a408011.
release of 2.1.0 need to go first

When wiping a volume we just rewrite all the data of the volume, not
only the content.  Since format gets overridden, we need to recreate the
volume.  However we can't do that for every possible format out there.
Since it was only coded for the ploop volume type, let's document what
might be the consequences instead of forbidding it for every other
format out there.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=868771Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The panic devices with models s390 and pseries are autogenerated.
For backwards compatibility reasons the devices are to be removed
when migrating.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Ever since virDomainCreateWithFlags() was introduced by de3aadaa
[drivers: add virDomainCreateWithFlags if virDomainCreate exists], the
domain ID retrieved with virDomainGetID() was incorrect for several
drivers after virDomainCreateWithFlags() was called. The API consumer
had to look up the domain anew to retrieve the correct ID.

For the ESX driver, this was fixed in 6139b274 [esx: Update ID after
starting a domain]. For the openvz driver, it was fixed in fd81a097
[openvzDomainCreateWithFlags: set domain id to the correct value]. The
test driver, the OpenNebula driver (removed in the meantime) and the
vbox driver were already updating the domain ID correctly in
domainCreate().

Copy over the ID in qemuDomainCreateWithFlags() to fix this for the qemu
driver, too.

Fixes: de3aadaa ("drivers: add virDomainCreateWithFlags if virDomainCreate exists")
Reported-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
Tested-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

Consider the following XML snippet:

    <memory model=''>
      <target>
        <size unit='KiB'>523264</size>
        <node>0</node>
      </target>
    </memory>

Whats wrong you ask? The @model attribute. This should result in
an error thrown into users faces during virDomainDefine phase.
Except it doesn't. The XML validation catches this error, but if
users chose to ignore that, they will end up with invalid XML.
Well, they won't be able to start the machine - that's when error
is produced currently. But it would be nice if we could catch the
error like this earlier.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The original name 'admin_uri_default' was introduced to our code by commit
dbecb87f. However, at that time we already had a separate config file for
admin library but the commit mentioned above didn't properly adjust the
config's option name. The result is that when we're loading the config, we
check a non-existent config option (there's not much to do with the URIs
anyway, since we only allow local connection). Additionally, virt-admin's man
page documents, that the default URI can be altered by setting
admin_uri_default option. So the fix proposed by this patch leaves the
libvirt-admin.conf as is and adjusts the naming in the code as well as in the
virt-admin's man page.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The virJSONValueObjectCreate only consumes the object on success, so on
failure we must free - from commit id 'f4441017' (found by Coverity).

https://bugzilla.redhat.com/show_bug.cgi?id=1356436

Commit id '56057900' altered the discovery of iSCSI node targets by
using the "--op nonpersistent". This caused issues for clean environments
or if by chance a "-m node -o delete" was executed.

Since each iSCSI Storage Pool has the required iSCSI target path, use
that and the virISCSINodeNew API in order to generate the iSCSI node record.

https://bugzilla.redhat.com/show_bug.cgi?id=1356436

According to RFC 3721 (https://www.ietf.org/rfc/rfc3721.txt), there are
two ways to "discover" targets in/for the iSCSI environment. Discovery
is the process which allows the initiator to find the targets to which
it has access and at least one address at which each target may be
accessed.

The method currently implemented in libvirt using the virISCSIScanTargets
API is known as "SendTargets" discovery. This method is more useful when
the target IP Address and TCP port information are available, e.g. in
libvirt terms the "portal". It returns a list of targets for the portal.
From that list, the target can be found. This operation can also fill an
iSCSI node table into which iSCSI logins may occur. Commit id '56057900'
altered that filling by adding the "--op nonpersistent" since it was
not necessarily desired to perform that for non libvirt related targets.

The second method is "Static Configuration". This method not only needs
the IP Address and TCP port (e.g. portal), but also the iSCSI target name.
In libvirt terms this would be the device path field from the iSCSI pool
<source> XML. This patch implements the second methodology using that
required device path as the targetname.

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>

Refactor the virStorageFileMatchesNNN methods so that
they don't take a struct FileFormatInfo parameter, but
instead get the actual raw dat items they needs. This
will facilitate reuse in other contexts.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

To collect all balloon statistics for all guests it was necessary to make
several libvirt requests. Now it's possible to get all balloon statiscs via
single connectGetAllDomainStats call.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

Is necessary to call it from other contexts, such as qemuDomainGetStatsBalloon.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>

This fixes commit 65bf0446 which introduced 'usable' stat.
Signed-off-by: NDerbyshev Dmitry <dderbyshev@virtuozzo.com>
Signed-off-by: NPavel Hrdina <phrdina@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>

To allow richer definitions of disk sources add infrastructure that will
allow to register functionst generating a JSON object based definition.

This infrastructure will then convert the definition to the proper
command line syntax and use it in cases where it's necessary. This will
allow to keep legacy definitions for back-compat when possible and use
the new definitions for the configurations requiring them.

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.

As gluster natively supports multiple hosts for failover reasons we can
easily add the support to the storage driver code in libvirt.

Extract the code setting an individual host into a separate function and
call them in a loop. The new code also tries to keep the debug log
entries sane.

Avoid a large block by tweaking the condition skipping empty drives and
split up the switch containing two branches having different purpose.

The disk source formatting code grew rather ugly and complex and it will
get worse. Extract it into a separated function to contain the mess.

Extract the code so that it can be called from multiple places. This
also removes a tricky fallthrough in the large switch in
qemuBuildNetworkDriveStr.

The function builds also non-uri strings for the various protocols.

Allow using 'ssh' protocol in backing chains and later for disks
themselves.

iSCSI is a bit odd in this aspect since it only supports URIs but using
the 'filename' property and does not have any alternative syntax.

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.

It's just read.

The cur_balloon also increases/decreases with dimm hotplug/unplug.
To be consistent, adjust the value for coldplug too. This was inconsistently
taken care when cur_ballon != memory to begin with. The patch fixes it
irrespective of that.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since commit c4bdff19, the path to the configuration file has been constructed
in the following manner:
 - if no config filename was passed to virConfLoadConfigPath, libvirt.conf was
 used as default
 - otherwise the filename was concatenated with
 "<config_dir>/libvirt/libvirt%s%s.conf" which in admin case resulted in
 "libvirt-libvirt-admin.conf.conf". Obviously, this non-existent config led to
 ignoring  all user settings in libvirt-admin.conf. This patch requires the
 config filename to be always provided as an argument with the concatenation
 being simplified.

 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1357364Signed-off-by: NErik Skultety <eskultet@redhat.com>

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.