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@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@redhat.com>