[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libguestfs
Subject:    Re: [Libguestfs] [PATCH] v2v: remove MAC address related information
From:       Michal Skrivanek <michal.skrivanek () redhat ! com>
Date:       2018-02-27 16:54:23
Message-ID: 01607A5D-CDA0-4D98-A799-7313686199E2 () redhat ! com
[Download RAW message or body]



> On 27 Feb 2018, at 17:41, Richard W.M. Jones <rjones@redhat.com> wrote:
> 
> On Tue, Feb 27, 2018 at 04:43:15PM +0100, Michal Skrivanek wrote:
> > > We're passing the source MAC through into the OVF (see rasd:MACAddress
> > > and v2v/create_ovf.ml).  Does oVirt use it?
> > 
> > no. Exactly for the reason Tomas mentioned, the MAC spaces are
> > almost always entirely different and we reallocate a different MAC
> > every time
> 
> That's oVirt's decision, and we can work around it as described by
> erasing MAC addresses when the target is oVirt.  The patch will need
> to be more complete because it must at the very least deal with
> NetworkManager & Windows.
> 
> However ... I'm pretty sure this is going to cause problems for oVirt.
> It will mean in some circumstances that ethernet ports are swapped
> (which can be serious - you don't want your public and private LANs to
> get swapped over, although usually the result will be failure rather
> than the guest sending out private information over a public port).
> 
> Also you'll have problems which anything which keys off the MAC
> address to derive system-unique numbers, like license servers.

The reason for all that is that oVirt has a concept of MacPool which is a set of MAC \
addresses (range) allowed in a particular DC. That's typically different than \
VMware's even though it could be configured to overlap. The constraints are coming \
from that - when the VM is added it cannot conflict with any VM already there (that \
can happen even for overlapping ranges) and such VM is invalid (we strive not to \
create it as such under no circumstances)

A clean way would be to use "add NIC" API which does the MAC allocation. In fact \
that's what's happening when we import a VM with NICs with no MACs internally. Maybe \
a better long-term solution would be to use the API in a similar way as upload API - \
to define/reserve NICs. That way virt-v2v does have the information which NIC it is \
and maybe it can map them correctly. Would it make sense to explore?

Thanks,
michal

> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-builder quickly builds VMs from scratch
> http://libguestfs.org/virt-builder.1.html


_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs


[prev in list] [next in list] [prev in thread] [next in thread]