Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Based on recent review comment - rather than have a spate of goto failxxxx,
change to a boolean based model. Ensures that the original error can be
preserved and cleanup is a bit more orderly if more objects are added.

Commit da665fbd introduced the following condition to virLXCProcessEnsureRootFS
and openvzReadFSConf:

if (!(<some_var> = virDomainFSDefNew()) < 0)

which broke the build on fedora with GCC 5.3.1: "logical not is only applied to
the left hand side of comparison".
Signed-off-by: NErik Skultety <eskultet@redhat.com>

The commit da665fbd introduced virStorageSourcePtr inside the structure
_virDomainFSDef. This is causing an error when libvirt is being compiled.

make[3]: Entering directory `/media/julio/8d65c59c-6ade-4740-9cdc-38016a4cb8ae
/home/julio/Desktop/virt/libvirt/src'
  CC       security/virt_aa_helper-virt-aa-helper.o
security/virt-aa-helper.c: In function 'get_files':
security/virt-aa-helper.c:1087:13: error: passing argument 2 of 'vah_add_path'
from incompatible pointer type [-Werror]
             if (vah_add_path(&buf, fs->src, "rw", true) != 0)
             ^
security/virt-aa-helper.c:732:1: note: expected 'const char *' but argument is
of type 'virStorageSourcePtr'
 vah_add_path(virBufferPtr buf, const char *path, const char *perms, bool
recursive)
 ^
cc1: all warnings being treated as errors

Adding the attribute "path" from virStorageSourcePtr fixes this issue.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

vz supports only a subset of tcp and udp parameters.

1. tcp type supports only 'raw' protocol.
2. udp type supports only same parameters of 'host' and 'service'
for 'bind' and 'connect'.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

After domain is in the domains list let's keep it there. This
is approach taken by qemu driver and vz vzDomainMigrateFinish3Params too.
It quite reasonable, driver domain object is fully constructed and
can be discovered by client later.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

  9c14a9ab introduced vzNewDomain function to enlist libvirt domain
object before actually creating vz sdk domain. Fix should fix
race on same vz sdk domain added event where libvirt domain object is
enlisted too. But later eb5e9c1e added locked checks for
adding livirtd domain object to list on vz sdk domain added event.
Thus now approach of 9c14a9ab is unnecessary complicated.

  See we have otherwise unuseful prlsdkGetDomainIds function only
to create minimal domain definition to create libvirt domain object.
Also vzNewDomain is difficult to use as it creates partially
constructed domain object.

  Let's move back to original approach where prlsdkLoadDomain do
all the necessary job. Another benefit is that we can now
take driver lock for bare minimum and in single place. Reducing
locking time have small disadvatage of double parsing on race
conditions which is typical if domain is added thru vz driver.
Well we have this double parse inevitably with current vz sdk api
on any domain updates so i would not take it here seriously.

  Performance events subscribtion is done before locked check and
therefore could be done twice on races but this is not the problem.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Vz containers are able to use ploop volumes from storage pools
to work upon.

To use filesystem type volume, pool name and volume name should be
specifaed in <source> :
   <filesystem type='volume' accessmode='passthrough'>
      <driver type='ploop' format='ploop'/>
      <source pool='guest_images' volume='TEST_POOL_CT'/>
      <target dir='/'/>
   </filesystem>

The information about pool and volume is stored in ct dom configuration:
<StorageURL>libvirt://localhost/pool_name/vol_name</StorageURL>
and can be easily obtained via PrlVmDevHd_GetStorageURL sdk call.

The only shorcoming: if storage pool is moved somewhere the ct
should be redefined in order to refresh the information aboot path
to root.hdd
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

We do not need to check domainf fs type there,
because it is done in prlsdkCheckUnsupportedParams.
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

New type of <devices> <filesystem type= 'volume'> is introduced.
This patch allows to use volumes for storing the filesystem, that is
accessed from the guest e.g. root directory for container.

To take advantage of volumes as a backend of filesystem volume
and pool names should be specified:
<filesystem type= 'volume'>
 <source pool='pool name' volume='volume name'/>
Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Signed-off-by: NOlga Krishtal <okrishtal@virtuozzo.com>

Adding domain to domain list on preparation step is not correct.
First domain is not fully constructed - domain definition is
missing. Second we can't use VIR_MIGRATE_PARAM_DEST_XML parameter
to parse definition as vz sdk can patch it by itself. Let's add/remove
domain on finish step. This is for synchronization purpose only so domain
is present/absent on destination after migration completion. Actually
domain object will probably be created right after actual vz sdk
migration start by vz sdk domain defined event.

We can not and should not sync domain cache on error path in finish step
of migration. We can not as we really don't know what is the reason of
cancelling and we should not as user should not make assumptions on
state on error path. What we should do is cleaning up temporary migration
state that is induced on prepare step but we don't have one. Thus
cancellation should be noop.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Free sdkdom on any result of prlsdkNewDomainByHandle.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

libvirt domain defined event is issued only on correspondent vz sdk
event. But in case event delivered before domain is added to
domain list we can mistakenly skip this event if prlsdkNewDomainByHandle
return NULL in case of domain is discovered in the list under
the driver lock. Let's return domain object in this case.
Now prlsdkNewDomainByHandle returns NULL only in case of
error which is more convinient.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

The first version of migration cookie was rather dumb resulting
in passing empty or unused fields here and there. Add flags to
specify what to bake to and eat from cookie so we deal only
with meaningful data. However for backwards compatibility
we still need to pass at least some faked fields sometimes.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Older libvirt versions send persistent XML in a migration cookie even
when VIR_MIGRATE_PERSIST_DEST flag is not used, but current libvirt
properly fails if the cookie contains unexpected flags. Thus migration
from old libvirt fails with

    internal error: Unsupported migration cookie feature persistent

unless VIR_MIGRATE_PERSIST_DEST flag is set.

https://bugzilla.redhat.com/show_bug.cgi?id=1320500Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

A nodedev device definition like this is required for testing
NodeDeviceCreateXML and NodeDeviceDestroy. So unless it's part
of the stock test:///default set there's no way to actually
invoke those functions for the default URI

Convert the individual XML documents into one big XML document
in the format expected by the non-default test://$PATH URI, and
use the same internal helpers for assembling the driver contents.

Upcoming patches need this defined later

Since commit 6381c89f, we're storing long long integers
instead of long integers. Rename the corresponding virConfType
value accordingly.

We use unsigned long long integers unless we need to store a
negative value. Rewrite the condition to make this more obvious.

The parameters for virConfGetValueLLong() were not aligned
properly.

The name of the function is not virConfGetValueULongLong().

virConfGetValueLLong() errors out if the value is too big to
fit into a long long integer, but claims the supported range
to be (0,LLONG_MAX) instead of (LLONG_MIN,LLONG_MAX).

For good measure.

When parsing numeric values, we always store them as unsigned
unless they're negative. We can use this fact to simplify the
logic by removing a bunch of unnecessary checks.

Commit 6381c89f changed virConfValue to store long long
integers instead of long integers; however, the temporary variable
used in virConfParseLong() was not updated accordingly, causing
trouble for 32-bit machines.

The code for parsing the different public syms files only differs
in the filenames and version prefix.

Unify it to a single subroutine.