Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Ian Jackson writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: 
don't use the new nic naming scheme"):
> Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: 
> don't use the new nic naming scheme"):
> > It is rather different. It is a hack put in by IanC to deal with
> > unreliable USB nic. IIRC the rule invokes ip to set the mac address.
> 
> Yikes.

I have looked at this again.  Part of the difficulty is the confusion
between these two things:

1. Making the same NICs show up with the same names in each of
   the installer and every boot.  Without this, the network
   configuration in /etc/network/interfaces (written by the installer)
   does not work, and also osstest is not able to properly configure
   the bridging (in /etc/network/interfaces, again).

2. On some broken NICs the MAC address has to be set manually.
   This is the function of
     ff9e0d8cbd9e "ts-host-install: Add force-mac-address host flag"
   Obviously this can only possibly work if there is only one NIC.

In Debian, in jessie and earlier, (1) is achieved by
/lib/udev/rules.d/75-persistent-net-generator.rules.  That maintains a
persistent database of MAC address <-> name mappings, in
/etc/udev/rules.d/70-persistent-net.rules.  When a previously seen NIC
shows up, it is renamed by 70-persistent-net.rules.  When a
not-previously-seen NIC shows up, 75-persistent-net-generator.rules
selects a new unique eth* name for it, adds a rule to
70-persistent-net.rules, and renames the NIC.

For guests which share the host's initrd this works fine because the
guest has a new MAC address.  Its NIC therefore gets a new name.  It
does not matter that that name is probably eth1 or something.  (Or,
maybe, if the host has many NICs, eth7 or something.)

In Debian upstream in stretch and later, (1) is achieved by the new
kernel netname scheme (which this patch disables).  I don't know
exactly how it is implemented, but the basic idea is to (mostly) use
the MAC address in the name.  These names are inconvenient to work
with because they are opaque, and they break some of osstest's (IMO
reasonable) assumptions.

I think that we should fix (1) by copying jessie's
/lib/udev/rules.d/75-persistent-net-generator.rules into installs of
stretch and later.  We will have to also copy the
70-persistent-net.rules generated in the installer into the target
system.  I think Julien has patches to do that ?

(2) is a different kettle of fish entirely.  It is slightly
unfortunate that ff9e0d8cbd9e edits 70-persistent-net.rules rather
than providing its own rules file - that is confusing.

I think ff9e0d8cbd9e avoids breaking guests which share the hosts
initrd, on jessie, simply because 70-persistent-net.rules is not in
the initrd at all.

Discussion surrounding
  "[16/19] Set mac address in interfaces(5) if force -mac-address is set"
suggests to me that in stretch, 70-persistent-net.rules *is* in the
initrd if it exists.  This is odd because I thought stretch had
dropped official support for this scheme.

Overall I think the right solution for stretch is:

 * Set net.ifnames=0 as this patch does.

 * Use the installer early command hook to install
   75-persistent-net-generator.rules in the initramfs.

 * If the installer does not do this already, use an installer
   late command hook to copy 70-persistent-net.rules from the
   installer to the target.

The above will fix (1) by reverting everything to the way it works on
jessie.  To fix (2) (which maybe worked as it was on jessie by
chance),

 * Use an early command hook to install something like the
   udev rule in ff9e0d8cbd9e but not into 70-persistent-net.rules.
   Instead, put it in 69-fixup-broken-nic.rules or something.
   That rule will not make it into the installed system so
   will cause no trouble for any guests.

 * Use a late command hook to fix the mac address in /e/n/i,
   as done in "[16/19] Set mac address in interfaces(5)..."

Does everyone agree ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel