<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 11:48 PM, Michal Skrivanek <span dir="ltr"><<a href="mailto:michal.skrivanek@redhat.com" target="_blank">michal.skrivanek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-h5"><div></div><div><br></div><div><br>On 07 Mar 2018, at 14:20, Arik Hadas <<a href="mailto:ahadas@redhat.com" target="_blank">ahadas@redhat.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 7, 2018 at 1:41 PM, Richard W.M. Jones <span dir="ltr"><<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>On Wed, Mar 07, 2018 at 01:26:39PM +0200, Arik Hadas wrote:<br>
> Interesting, that contradicts my intuition - I would imagine that most of<br>
> the things are actually known (the things that appear in the top-level part<br>
> of the domain xml: memory size, memory size, num of CPUs, name,.. ) and<br>
> only things that depend on the content of the disks or things that depend<br>
> on installations during the conversion are unknown.<br>
> But anyway, it is enough IMO to send the name, memory, CPU and size of the<br>
> disks to present something useful to the user and make the necessary<br>
> validations at that point.<br>
<br>
</span>Some of those things are known, but they didn't seem to me to be that<br>
interesting for oVirt to know in advance. In any case what's<br>
precisely known before conversion is:<br>
<br>
(1) The 'source' struct and sub-structs:<br>
<br>
<a href="https://github.com/libguestfs/libguestfs/blob/ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L59" rel="noreferrer" target="_blank">https://github.com/libguestfs/<wbr>libguestfs/blob/ba53251ab912b8<wbr>bac9e00c1022adc6ba9bdf70a3/<wbr>v2v/types.mli#L59</a><br>
<br>
(2) The 'overlay' struct (one per disk):<br>
<br>
<a href="https://github.com/libguestfs/libguestfs/blob/ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L175" rel="noreferrer" target="_blank">https://github.com/libguestfs/<wbr>libguestfs/blob/ba53251ab912b8<wbr>bac9e00c1022adc6ba9bdf70a3/<wbr>v2v/types.mli#L175</a><br>
<br>
Note only virtual disk size is known, which is near to useless for<br>
provisioning storage.<br>
<br>
(3) The 'target' struct (one per disk):<br>
<br>
<a href="https://github.com/libguestfs/libguestfs/blob/ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L191" rel="noreferrer" target="_blank">https://github.com/libguestfs/<wbr>libguestfs/blob/ba53251ab912b8<wbr>bac9e00c1022adc6ba9bdf70a3/<wbr>v2v/types.mli#L191</a><br>
<br>
What's unknown are guest capabilities (hence nothing about what<br>
devices should be presented to the guest), inspection data, target bus<br>
mapping, real size of disks, etc.<br>
<span><br></span></blockquote><div><br></div><div>I see. I think it is sufficient - the information from the 'source' struct seems enough just to produce a representative VM entity in the database that would be reflected in the UI with status 'importing' and for general validations, </div></div></div></div></div></blockquote><div><br></div></div></div>For having an entity, yes. For meaningful validations, not really. </div></blockquote><div><br></div><div>I was thinking mostly about validating the name and the amount of free space in the target storage domain.</div><div>But in the future, when/if the imported VMs could be from different architecture (PPC?) or different CPU type (q35?) we can also validate that the target cluster is valid.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>It's not so interesting to see much in oVirt, at least not for the virt-v2v command line usage</div><div><br></div></div></blockquote><div><br></div><div>Functionality-wise, I agree.</div><div>But in a serious management application you don't expect to see memory=0 or memory=N/A when you open the general tab of the VM that is being imported. If we can easily get the information from the 'source' struct, I think we should.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>and the estimated size on the 'target' struct would be enough for storage validations and optionally for choosing the right target storage domain. The other things are relatively hidden in oVirt's UI and can be added at the last phase.</div></div></div></div></div></blockquote><div><br></div></span>What I do not like that much about is that you change the VM at the end substantially, and for the import duration it's locked anyway</div><div>The name has a value, and progress, but again, only for a oVirt GUI user - and when you are driving the process from cmdline it's just not that important</div></div></div></blockquote><div><br></div><div>Right, but I tend to think that it's better to generalize the process in a way that the cmdline flow will make an extra step(s) rather than having separate and different flows.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><br></div><div>It's not so difficult to do it like that "externally" - just blindly create a completely stub VM in your caller app(wrapper; another integration), and then replace it. We do not need to push that into v2v directly </div><div><span class="gmail-"><br></span></div></div></div></blockquote><div><br></div><div>It depends on the amount and quality of validations you want to make at the beginning of the process and whether or not ovirt-engine should instruct v2v where to upload the disks to (maybe there should be an option to upload a disk without specifying the target storage domain so it will be selected automatically).</div><div>v2v will anyway need to trigger a call to ovirt-engine in order to create that context, that wrapper command. If the data we need at the beginning is already available to v2v at that point, providing it to that call shouldn't be that complex, right?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>BTW, that's how import from VMware/Xen currently works - we add a VM entity based on the domain XML we get from vCenter and at the last phase add the missing parts when getting the generated OVF from virt-v2v. So for instance, the VM would have no graphics device until that last phase.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
Rich.<br>
<br>
--<br>
Richard Jones, Virtualization Group, Red Hat <a href="http://people.redhat.com/~rjones" rel="noreferrer" target="_blank">http://people.redhat.com/~rjon<wbr>es</a><br>
Read my programming and virtualization blog: <a href="http://rwmj.wordpress.com" rel="noreferrer" target="_blank">http://rwmj.wordpress.com</a><br>
</span>virt-top is 'top' for virtual machines. Tiny program with many<br>
powerful monitoring features, net stats, disk stats, logging, etc.<br>
<a href="http://people.redhat.com/~rjones/virt-top" rel="noreferrer" target="_blank">http://people.redhat.com/~rjon<wbr>es/virt-top</a><br>
</blockquote></div><br></div></div>
</div></blockquote></span><span class="gmail-"><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>Devel mailing list</span><br><span><a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a></span><br><span><a href="http://lists.ovirt.org/mailman/listinfo/devel" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></span></div></blockquote></span></div></div></div>
</blockquote></div><br></div></div>