<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">&lt;<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Mar 07, 2018 at 01:26:39PM +0200, Arik Hadas wrote:<br>
&gt; Interesting, that contradicts my intuition - I would imagine that most of<br>
&gt; the things are actually known (the things that appear in the top-level part<br>
&gt; of the domain xml: memory size, memory size, num of CPUs, name,.. ) and<br>
&gt; only things that depend on the content of the disks or things that depend<br>
&gt; on installations during the conversion are unknown.<br>
&gt; But anyway, it is enough IMO to send the name, memory, CPU and size of the<br>
&gt; disks to present something useful to the user and make the necessary<br>
&gt; validations at that point.<br>
<br>
</span>Some of those things are known, but they didn&#39;t seem to me to be that<br>
interesting for oVirt to know in advance.  In any case what&#39;s<br>
precisely known before conversion is:<br>
<br>
(1) The &#39;source&#39; 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/<wbr>ba53251ab912b8bac9e00c1022adc6<wbr>ba9bdf70a3/v2v/types.mli#L59</a><br>
<br>
(2) The &#39;overlay&#39; 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/<wbr>ba53251ab912b8bac9e00c1022adc6<wbr>ba9bdf70a3/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 &#39;target&#39; 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/<wbr>ba53251ab912b8bac9e00c1022adc6<wbr>ba9bdf70a3/v2v/types.mli#L191</a><br>
<br>
What&#39;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 class=""><br></span></blockquote><div><br></div><div>I see. I think it is sufficient - the information from the &#39;source&#39; struct seems enough just to produce a representative VM entity in the database that would be reflected in the UI with status &#39;importing&#39; and for general validations, and the estimated size on the &#39;target&#39; struct would be enough for storage validations and optionally for choosing the right target storage domain. The other things are relatively hidden in oVirt&#39;s UI and can be added at the last phase.</div><div><br></div><div>BTW, that&#39;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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
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/~<wbr>rjones</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 &#39;top&#39; 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/~<wbr>rjones/virt-top</a><br>
</blockquote></div><br></div></div>