> On 27 Feb 2018, at 13:57, Richard W.M. Jones <[email protected]> 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 <[email protected]> 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 _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
