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

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in ubuntu.
https://bugs.launchpad.net/bugs/724601

Title:
  UEC images should disable udev persistent net rules

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Reply via email to