On Tuesday, 27 February 2018 13:34:09 CET Richard W.M. Jones wrote:
On Tue, Feb 27, 2018 at 12:53:08PM +0100, Pino Toscano 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.
We preserve the MAC address in metadata. On the other hand AIUI this
patch only removes the association in the ifcfg files and the guest
will reassociate it when it boots (albeit it might then mix up the
ethernet interfaces so that's not good).
Yes, this is my concern, i.e. that the guest network configuration
might break.
There's IMHO a bigger problem which is not being addressed:
https://bugzilla.redhat.com/show_bug.cgi?id=1318922
Possibly there could be also
https://bugzilla.redhat.com/show_bug.cgi?id=1451597
> What's the reason behind this patch?
There's a bit of background which is missing. Tomáš and I had some
discussions (privately, unfortunately) with the ManageIQ developers
who are integrating virt-v2v into MIQ/CloudForms. Their existing
software runs a separate virt-sysprep step on guests after they have
been converted by virt-v2v. They disable all sysprep the operations
except for just a couple, including ‘net-hwaddr’, so the effect is
roughly the same as this patch.
The question was raised why they need to do that as a separate step
and why virt-v2v doesn't do it.
This is what my question was about: I do not understand why this
sysprep step (to remove the MAC addresses) is done in the first place,
and without this information it is hard to put extra conversion steps
in v2v.
What issues were fixed by sysprep'ing the converted guest?
And indeed there was some discussion
about whether or not converted guests need a new MAC address -- it's
at best unclear -- it is thought that VMware might reuse MAC addresses
which have "left" the hypervisor, although no one knows if that's
really true or not.
IMHO the first thing to do would be deciding on whether the MAC address
need to be removed from the guest or not.
If it is decided they need to go, then my suggestion would be to add a
new command line option to tune this behaviour:
- if not specified, then the MAC addresses are preserved in both guest
and metadata
- if specified, then the MAC addresses will not be preserved even in
the metadata
--
Pino Toscano