UEC images should disable udev persistent net rules

[Alex Bligh]

Binary package hint: cloud-init

Persistent interface naming should be disabled in UEC images, as it causes more harm that good.

Firstly, cloud systems generally expect the interfaces to be created in the order they are created in the hypervisor. Renaming them (particularly when some images are persistent, and some are not) is confusing.

Secondly, it causes inconsistency, in that the Xen pv interfaces (for instance) are ignored, whereas the kvm ones aren't.

Thirdly, it causes terrible problems (read unbootable machines) on old Xen (and perhaps newer Xen), where the same interface appears twice - once as an emulated HVM interface, and one as a PV on HVM interface each with the same MAC address. That makes for confusion, particularly given one subsystem is ignored and one isn't. Essentially the interfaces constantly rename.

The (very easy) solution is to disable persistent net interface renaming.

Related bugs:
 * bug 726635: udev should not create a persistency-rule for virtualbox virtio network card
   see comment 2.
 * bug 719418: Do not create persistent name rules for eucalyptus interfaces
 * bug 341006: ease cloning of virtual images by disabling mac address rules
   (see comment 18)

[Dave Walker (davewalker)]

Thanks for reporting this bug, is this and bugs 726635 both duplicates of the same issue demonstrated differently?

[Alex Bligh (ubuntu-alex-org)]

No, these are different bugs I think, though they relate to the same sort of issue.

Bug 726635 says that even on conventional (non-UEC) images, MAC addresses ranges used by Virtualbox should be ignored in the persistent udev rules. That's fair enough, though I note Xen and KVM were treated differently last time I looked (Xen is triggered by subsystem, which fails to match HVM emulated net devices but matches PV on HVM devices).

This bug says that on a UEC image, then by definition ANY udev persistent net rules handling is unnecessary and can only cause problems. The net interfaces are ALWAYS virtual, and may do things which are unexpected and undesirable in certain environments. An example is where the image comes up with a different MAC address when booted on a different compute node/cluster that provides a different MAC range; this is just about guaranteed to happen if you move an image with a persistent boot disk between one cloud and another. Another example of it causing problems is running on older Xen (see above). So on the UEC image persistent interface naming should always be disabled, irrespective of MAC address whitelist and subsystem checking (which is not reliable). I believe Scott Moser at Canonical has had problems too (I'm not sure precisely what); he encouraged me to report this so he may be able to add detail.

A less drastic alternative to completely disabling it would be to look at something in /etc/defaults which could then be used by people running non-UEC images on virtual systems too. I'm not sufficiently familiar with udev language to know how that could be incorporated into lib/udev/rules.d/75-persistent-net-generator.rules

[Alex Bligh (ubuntu-alex-org)]

From the manpage of udev: "Rule files are required to have a unique name, duplicate file names are ignored. Files in /etc/udev/rules.d/ have precedence over files with the same name in /lib/udev/rules.d/. This can be used to ignore a default rules file if needed.".

Untested, but perhaps on UEC images, creating an /etc/udev/rules.d/75-persistent-net-generator.rules (NOT 70-persistent-net.rules) which essentially empty would do the trick.

[Alex Bligh (ubuntu-alex-org)]

Further example of why this is needed: see my comment on Bug 726635. VirtualBox appears to use a "borrowed" MAC range, rather than an officiant assignment. That means it's probably not a great idea to use that MAC address range as a basis for black/whitelisting.

[James Falcon (falcojr)]

UEC is no longer supported