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

On 27 Feb 2018, at 13:57, Richard W.M. Jones <rjones(a)redhat.com&gt; 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(a)redhat.com&gt; 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?

> 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.

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