[Libguestfs] [PATCH] v2v: remove MAC address related information

[Michal Skrivanek]

> On 27 Feb 2018, at 13:57, Richard W.M. Jones <rjones at 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 at 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