[ovirt-devel] [ovirt-users] Unremovable disks created through the API

[Tomáš Golembiovský]

Hi,

this sounds like a good idea in general. Few interconnected questions
though...

On Wed, 7 Mar 2018 10:42:31 +0200
Arik Hadas <ahadas at redhat.com> wrote:

> IMHO, the process should be comprised of:
> 1. virt-v2v calls an API with the (probably partial since the OS and other
> things are unknown at that point) OVF configuration
> 2. virt-v2v uploads the disks
> 3. virt-v2v provides the up-to-date configuration
> 
> Step #1 will enable ovirt-engine:
> 1. Most importantly, to cleanup uploaded disks in case of an error during
> the import process. Otherwise, we require the client to clean them up,
> which can be challenging (e.g., if the virt-v2v process crashes).

Who will handle the removal in case of problems? Engine after timeout?
Or is the only benefit that administrator can remove all disks in one
step by removing the VM?

Note that the uploads do not timeout at the moment. However strange that
might be. So I assume removing the disks/VM will be impossible anyway
because of locking.


> 2. To inform the user that the process has started - so he won't get
> surprised by seeing disks being uploaded suddenly. That will give a context
> to these upload operations.

The uploaded disks will still remain unattached though. Or do you plan
for Engine to create and attach the disks?


> 3. To inform the user about the progress of the import process, much like
> we do today when importing VMs from vSphere to RHV.

How will this be handled? Will Engine report the progress in the Virtual
Machines view and compute something based on the upload progress?

Tomas

> 4. To perform validations on the (partial) VM configuration, e.g.,
> verifying that no VM with the same name exists/verifying there is enough
> space (optionally mapping different disks to different storage devices) and
> so on, before uploading the disks.
>
> 
> The gaps I see:
> 1. We don't have a command for step #1 yet but that's something we can
> provide relatively quickly. We need it also to support uploading an OVA via
> oVirt's webadmin.
> 2. We have a command for step #3, but it is not exposed via the API.


-- 
Tomáš Golembiovský <tgolembi at redhat.com>