Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Semantics of the libvirt helper are more clear. This change also allows
to clean up some pieces of code.

The 'uuid' field in virDomainDefPtr is not a pointer, it is a
fixed length array. Calling VIR_ALLOC on it is thus wrong and
leaks memory.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

These all existed before virfile.c was created, and for some reason
weren't moved.

This is mostly straightfoward, although the syntax rule prohibiting
write() had to be changed to have an exception for virfile.c instead
of virutil.c.

This movement pointed out that there is a function called
virBuildPath(), and another almost identical function called
virFileBuildPath(). They really should be a single function, which
I'll take care of as soon as I figure out what the arglist should look
like.

The source code base needs to be adapted as well. Some files
include virutil.h just for the string related functions (here,
the include is substituted to match the new file), some include
virutil.h without any need (here, the include is removed), and
some require both.

POSIX says that both basename() and dirname() may return static
storage (aka they need not be thread-safe); and that they may but
not must modify their input argument.  Furthermore, <libgen.h>
is not available on all platforms.  For these reasons, you should
never use these functions in a multi-threaded library.

Gnulib instead recommends a way to avoid the portability nightmare:
gnulib's "dirname.h" provides useful thread-safe counterparts.  The
obvious dir_name() and base_name() are GPL (because they malloc(),
but call exit() on failure) so we can't use them; but the LGPL
variants mdir_name() (malloc's or returns NULL) and last_component
(always points into the incoming string without modifying it,
differing from basename semantics only on corner cases like the
empty string that we shouldn't be hitting in the first place) are
already in use in libvirt.  This finishes the swap over to the safe
functions.

* cfg.mk (sc_prohibit_libgen): New rule.
* src/util/vircgroup.c: Fix offenders.
* src/parallels/parallels_storage.c (parallelsPoolAddByDomain):
Likewise.
* src/parallels/parallels_network.c (parallelsGetBridgedNetInfo):
Likewise.
* src/node_device/node_device_udev.c (udevProcessSCSIHost)
(udevProcessSCSIDevice): Likewise.
* src/storage/storage_backend_disk.c
(virStorageBackendDiskDeleteVol): Likewise.
* src/util/virpci.c (virPCIGetDeviceAddressFromSysfsLink):
Likewise.
* src/util/virstoragefile.h (_virStorageFileMetadata): Avoid false
positive.
Signed-off-by: NEric Blake <eblake@redhat.com>

Ensure that all drivers implementing public APIs use a
naming convention for their implementation that matches
the public API name.

eg for the public API   virDomainCreate make sure QEMU
uses qemuDomainCreate and not qemuDomainStart
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

It will simplify later work if the sub-drivers have dedicated
APIs / field names. ie virNetworkDriver should have
virDrvNetworkOpen and virDrvNetworkClose methods
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Ensure that the driver struct field names match the public
API names. For an API virXXXX we must have a driver struct
field xXXXX. ie strip the leading 'vir' and lowercase any
leading uppercase letters.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The parallels storage driver declared some loop variables
inside the for(;;). This is not allowed by libvirt coding
standards
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The bfree and blocks fields are supposed to be in units of frsize.  We were
calculating capacity correctly using those units, but the available
calculation was using bsize instead.  Most file systems report these as the
same value specifically because many programs are buggy, but that is no
reason to rely on that behavior, or to behave inconsistently.

This bug has been present since e266ded2 (2008) and aa296e6c, when the code
was originally introduced (the latter via cut and paste).
Signed-off-by: NSage Weil <sage@newdream.net>

As a step towards making virDomainObjList thread-safe turn it
into an opaque virObject, preventing any direct access to its
internals.

As part of this a new method virDomainObjListForEach is
introduced to replace all existing usage of virHashForEach

The APIs names for accessing the domain list object are
very inconsistent. Rename them all to have a standard
virDomainObjList prefix.

Added some messaging to indicate possible failure from virXPathULongLong()
as well

Ignore the return in parallelsMakePoolName() since subsequent check
validates name was allocated.

Move part, which deletes existing volume, to a new function
parallelsStorageVolumeDefRemove so that we can use it later
in parallels_driver.c
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Read disk images size from xml description and fill
virStorageVolDef.capacity and allocation (let's consider
that allocation is the same as capacity, calculating real
allcoation will be implemented later).
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Disk images in Parallels Cloud Server stored in directories. Each
one has files with data and xml description of an image stored in
file DiskDescriptior.xml.

Since we have to support 'detached' images, which are not used by
any VM, the better way to collect info about volumes is searching for
directories with a file DiskDescriptior.xml in each VM directory.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We always have to close opened dir and free 'path'.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

There are no storage pools in Parallels Cloud Server -
All VM data stored in a single directory: config, snapshots,
memory dump together with disk images.

Let's look through list of VMs and create a storage pool for
each directory, containing VMs.

So if you have 3 vms: /var/parallels/vm-1.pvm,
/var/parallels/vm-2.pvm and /root/test.pvm - 2 storage pools
appear: -var-parallels and -root. xml descriptions of the pools
will be saved in /etc/libvirt/parallels-storage, so UUIDs will
not change netween connections to libvirt.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

We don't support unprivileged users anymore, so remove code, which
selects configuration directory depending on user.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Move code for loading inforation about pools to a separate
function - parallelsLoadPools.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

The virStateInitialize method and several cgroups methods were
using an 'int privileged' parameter or similar for dual-state
values. These are better represented with the bool type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This will simplify the refactoring of the ESX storage driver to support
a VMFS and an iSCSI backend.

One of the tasks the storage driver needs to do is to decide which backend
driver needs to be invoked for a given request. This approach extends
virStoragePool and virStorageVol to store extra parameters:

1. privateData: stores pointer to respective backend storage driver.
2. privateDataFreeFunc: stores cleanup function pointer.

virGetStoragePool and virGetStorageVol are modfied to accept these extra
parameters as user params. virStoragePoolDispose and virStorageVolDispose
checks for cleanup operation if available.

The private data pointer allows the ESX storage driver to store a pointer
to the used backend with each storage pool and volume. This avoids the need
to detect the correct backend in each storage driver function call.

In the XML warning, we print a virsh command line that can be used to
edit that XML. This patch prints UUIDs if the entity name contains
special characters (like shell metacharacters, or "--" that would break
parsing of the XML comment). If the entity doesn't have a UUID, just
print the virsh command that can be used to edit it.

Found this when building on RHEL5:

parallels/parallels_storage.c: In function 'parallelsStorageOpen':
parallels/parallels_storage.c:180: error: 'for' loop initial declaration used outside C99 mode

(and similar error in parallels_driver.c). This was in spite of
configuring with "-Wno-error".

https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.

* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/;  If/.  If/

To create a new VM in Parallels Clud Server we should issue
"prlctl create" command, and give path to the directory,
where VM should be created. VM's storage will be in that
directory later. So in this first version find out location
of first VM's hard disk and create VM there.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>

Parallels Cloud Server has one serious discrepancy with libvirt:
libvirt stores domain configuration files in one place, and storage
files in other places (with the API of storage pools and storage volumes).
Parallels Cloud Server stores all domain data in a single directory,
for example, you may have domain with name fedora-15, which will be
located in '/var/parallels/fedora-15.pvm', and it's hard disk image will be
in '/var/parallels/fedora-15.pvm/harddisk1.hdd'.

I've decided to create storage driver, which produces pseudo-volumes
(xml files with volume description), and they will be 'converted' to
real disk images after attaching to a VM.

So if someone creates VM with one hard disk using virt-manager,
at first virt-manager creates a new volume, and then defines a
domain. We can lookup a volume by path in XML domain definition
and find out location of new domain and size of its hard disk.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>