Since volumes in a virtual storage pool of type 'disk' are partitions,
then need to be named after the disk name with sequential numbers rather
than using the VM and disk names.
Also, the format passed by the user is the one used when creating the volume.
However in the VM definition for logical and disk volumes, the format should
be set to raw.
libvirt doesn't support attaching RBD storage pool volumes to a VM.
For instance, a disk with such a source is invalid:
<source pool='rbd-pool' volume='rbd-volume'/>
And needs to be replaced with:
<source protocol="rbd" name="rbd-pool-name/rbd-volume">
<host name="hostname" port="7000"/>
<auth username='myuser'>
<secret type='ceph' usage='mypassid'/>
</auth>
</source>
This means that we need to fetch the connection data from the pool
definition and convert the volume disk definition into a network one
when creating the VM.
This also means that when purging the VM we need to search for the
pool by looking in every pool's XML to delete the volume.
If a virtual machine has disks of volume types, they will now be
reported by the virt._get_disk() function and all the user-exposed
functions using it like virt.get_disks(), virt.vm_info() and
virt.full_info().
Since the format of a volume may be of interest and could help to tell
if two volumes are similar, output this information in the
virt.volume_infos function.
There is no need to generate MAC addresses in the virt module if the
user hasn't provided any. This only makes it harder to make the
difference between a real mac address change from the user and a new
generated one.
Now the mac address is not written in the domain XML definition if not
provided by the user. This avoids unnecessary changes when applying
virt.running.
In order to support creating VMs with disk on more storage pools like
iSCSI, disks, LVM, RBD, etc, virt.init needs to handle disks not only as
files, but also as libvirt volumes.
Te virt.pool_capabilities function computes a lot of interesting values
on the virtual storage pool types. Extract the logic of it into
virt._pool_capabilities for reuse.
Extract the libvirt-handling code from virt.capabilities into a
virt._capabilities function accepting an opened libvirt connection.
This allows reusing the code in other functions with easy connection
handling.
When using volumes the user can just copy the template disk image into
the target path. In such a case, the image needs to be uploaded into the
volume.
In the same vein than pool_define and network_define, expose a
volume_define function to let users create a volume without needing to
know all of libvirt's XML details.
In order to avoid connection multiple times when reusing this function
in the virt module, create _define_vol_xml_str not caring about the
connection opening and closing.
In order to generate almost all the volumes that libvirt can handle, add
the type, backingStore, permissions and allocation parameters to the
virt._gen_vol_xml() function.
Also make the format parameter optional since libvirt has default values
depending on the storage backend.
In the near future gen_vol_xml will be able to handle many volume types,
not only for ESX volumes. For this, clean up the function from all the
ESX-specifics code and move them to the caller code.
The volume key and target path values have also been removed since those
are read-only elements that should not be provided for volume creation
as per https://libvirt.org/formatstorage.html#StorageVol
