<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 1:01 PM, Tomáš Golembiovský <span dir="ltr"><<a href="mailto:tgolembi@redhat.com" target="_blank">tgolembi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
this sounds like a good idea in general. Few interconnected questions<br>
though...<br>
<span class=""><br>
On Wed, 7 Mar 2018 10:42:31 +0200<br>
Arik Hadas <<a href="mailto:ahadas@redhat.com">ahadas@redhat.com</a>> wrote:<br>
<br>
> IMHO, the process should be comprised of:<br>
> 1. virt-v2v calls an API with the (probably partial since the OS and other<br>
> things are unknown at that point) OVF configuration<br>
> 2. virt-v2v uploads the disks<br>
> 3. virt-v2v provides the up-to-date configuration<br>
><br>
> Step #1 will enable ovirt-engine:<br>
> 1. Most importantly, to cleanup uploaded disks in case of an error during<br>
> the import process. Otherwise, we require the client to clean them up,<br>
> which can be challenging (e.g., if the virt-v2v process crashes).<br>
<br>
</span>Who will handle the removal in case of problems? Engine after timeout?<br>
Or is the only benefit that administrator can remove all disks in one<br>
step by removing the VM?<br></blockquote><div><br></div><div>So I was thinking that the wrapper command will hold the amount of disks that should be uploaded for the VM.</div><div>If for some predefined period of time no new disk is added or an upload doesn't make any progress (assuming the uploads are done sequentially), to fail the import operation and that would roll back the resources (disks, VMs) that were created as part of the import process.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Note that the uploads do not timeout at the moment. However strange that<br>
might be. So I assume removing the disks/VM will be impossible anyway<br>
because of locking.<br></blockquote><div><br></div><div>Yeah, I think no timeout was defined because uploading from the browser is relatively fragile and we didn't want the upload to fail, and the partial disks to be removed, due to browser issues but rather to be able to resume their upload. But different logic can be implemented in the wrapping command.</div><div>As for locking, we don't have to call RemoveDisk but instead, to terminate the upload which will eventually remove the disks.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> 2. To inform the user that the process has started - so he won't get<br>
> surprised by seeing disks being uploaded suddenly. That will give a context<br>
> to these upload operations.<br>
<br>
</span>The uploaded disks will still remain unattached though. Or do you plan<br>
for Engine to create and attach the disks?<br></blockquote><div><br></div><div>Right, so when we have that "context" and a VM entity in the databse, we can attach the disks to the VM when they are created.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> 3. To inform the user about the progress of the import process, much like<br>
> we do today when importing VMs from vSphere to RHV.<br>
<br>
</span>How will this be handled? Will Engine report the progress in the Virtual<br>
Machines view and compute something based on the upload progress?<br></blockquote><div><br></div><div>Yes, I don't see why not showing that in the status field (at the VMs tab) as we do today for VMs that are being imported.</div><div>The engine would need to know the estimated actual sizes of the disks in order to compute it though.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Tomas<br>
<div class="HOEnZb"><div class="h5"><br>
> 4. To perform validations on the (partial) VM configuration, e.g.,<br>
> verifying that no VM with the same name exists/verifying there is enough<br>
> space (optionally mapping different disks to different storage devices) and<br>
> so on, before uploading the disks.<br>
><br>
><br>
> The gaps I see:<br>
> 1. We don't have a command for step #1 yet but that's something we can<br>
> provide relatively quickly. We need it also to support uploading an OVA via<br>
> oVirt's webadmin.<br>
> 2. We have a command for step #3, but it is not exposed via the API.<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Tomáš Golembiovský <<a href="mailto:tgolembi@redhat.com">tgolembi@redhat.com</a>><br>
</font></span></blockquote></div><br></div></div>