Libguestfs - Feb 2018 - Re: [PATCH] v2v: remove MAC address related information

> On 27 Feb 2018, at 13:57, Richard W.M. Jones <rjones@redhat.com>
wrote:
> 
> On Tue, Feb 27, 2018 at 01:34:21PM +0100, Tomáš Golembiovský wrote:
>> On Tue, 27 Feb 2018 12:53:08 +0100
>> Pino Toscano <ptoscano@redhat.com> wrote:
>> 
>>> On Tuesday, 27 February 2018 12:35:36 CET Tomáš Golembiovský wrote:
>>>> Remove ties to MAC address because it is likely to change.  
>>> 
>>> v2v tries to preserve the MAC address of network interfaces; few
months
>>> ago we did a fix regarding this:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1506572
>>> 
>>> The approach of this patch is IMHO not good, since it removes the
MAC
>>> address from the network-scripts, but still the rest of v2v will
try
>>> to preserve the MAC addresses.
>>> 
>>> What's the reason behind this patch?
>> 
>> Reason is that the MAC address is likely to change after the conversion
>> because the environment uses different MAC prefix. It depends on the
>> management system. For example the default pool in oVirt has prefix
>> 00:1A:4A:... registered to Qumranet Inc. I don't know what VMware
has as
>> as default. Big companies probably have their own prefix and thus are
>> OK.
> 
> 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
> 
>> Sure, you can have custom MAC addresses with different prefix on your
>> network. I can't say if that is good idea or bad idea.
> 
> Every (real) ethernet card comes with a different MAC address, with a
> different prefix for each vendor, so at least in theory there is no
> problem here.  It's not an issue for KVM either.  But it might be an
> issue for a particular management system, say if oVirt is hard-coding
> that prefix somewhere, or is ignoring the rasd:MACAddress field.
> 
>> It seems to me that this dual approach is right thing to do. Remove the
>> reference from guest so it is ready for new MAC, but leave the old MAC
>> in metadata. That way the management system can decide what is the
right
>> way to do.
> 
> The problem is going to be that ethernet ports get swapped around.
> 
> The other problem is that even if this is a good idea, Windows also
> embeds the MAC address somewhere in the Registry and we aren't
> touching that.  Plus there's likely to be multiple other places in
> Linux where it is stored, NetworkManager, systemd-networkd, etc.
> 
> This suggests that perhaps we should do this conditional on the target
> hypervisor, but we'd need more information about what oVirt is doing
> first.
conditional sounds good. for ovirt specifically it may be unconditionally
cleared
> 
> 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

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.

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

> 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