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
Whell functions, on a minion, must run with the master running along side the minion.
We now copy the master config to the minion's configuration directory just the wheel tests since the test suite master and minion(s) do not share the same configuration directory
