3:48 p.m.
On 07 Mar 2018, at 14:20, Arik Hadas <ahadas(a)redhat.com> wrote:
On Wed, Mar 7, 2018 at 1:41 PM, Richard W.M. Jones <rjones(a)redhat.com>
wrote:
On Wed, Mar 07, 2018 at 01:26:39PM +0200, Arik Hadas wrote:
> Interesting, that contradicts my intuition - I would imagine that most of
> the things are actually known (the things that appear in the top-level
part
> of the domain xml: memory size, memory size, num of CPUs, name,.. ) and
> only things that depend on the content of the disks or things that depend
> on installations during the conversion are unknown.
> But anyway, it is enough IMO to send the name, memory, CPU and size of
the
> disks to present something useful to the user and make the necessary
> validations at that point.
Some of those things are known, but they didn't seem to me to be that
interesting for oVirt to know in advance. In any case what's
precisely known before conversion is:
(1) The 'source' struct and sub-structs:
https://github.com/libguestfs/libguestfs/blob/
ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L59
(2) The 'overlay' struct (one per disk):
https://github.com/libguestfs/libguestfs/blob/
ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L175
Note only virtual disk size is known, which is near to useless for
provisioning storage.
(3) The 'target' struct (one per disk):
https://github.com/libguestfs/libguestfs/blob/
ba53251ab912b8bac9e00c1022adc6ba9bdf70a3/v2v/types.mli#L191
What's unknown are guest capabilities (hence nothing about what
devices should be presented to the guest), inspection data, target bus
mapping, real size of disks, etc.
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,
For having an entity, yes. For meaningful validations, not really.
It's not so interesting to see much in oVirt, at least not for the virt-v2v
command line usage
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.
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
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
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
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.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel