Just my two cents here regarding #21:
Sorting is fine, as long as the network adapters are stable. I today had
a re-ordering issue with a VM, which previously had two interfaces and
was configured as such. Then I added another one, and it became eth0,
changing the numbering of all other VMs.
I
This is from dmesg:
[0.932308] vmxnet3 :0b:00.0 eth0: NIC Link is Up 1 Mbps
[0.965537] vmxnet3 :0c:00.0 eth1: NIC Link is Up 1 Mbps
[0.973137] vmxnet3 :13:00.0 eth2: NIC Link is Up 1 Mbps
[0.979222] vmxnet3 :14:00.0 eth3: NIC Link is Up 1 Mbps
[
I know it's too old, but today i have big problem without persistent net rules.
(sorry for my English)
I have VMWare 5.5.0 host and Ubuntu 12.04 guest with many virtual NICs (with
MACs 00:0c:29*)
Today I updated kernel from 3.13.0-32 to 3.13.0-45
Rebooted VM
Lost connection to my VM over one of
While it helps in a pragmatic kind of way, carving out exemptions is
really a kludge.
The issue is that both aspects of the issue are valid. Persistence is
important in many situations but in others, it's more important to not
have things changing when they don't need to be changing. Arguably,
Actually, it occurs to me that if the down-process scripts were written
how I suggested above, the whole persistent-nic thing would be moot
except as a convenience to us silly humans. And that's as it should be.
I guess the meat of the matter boils down to What to you mean when you
say 'eth0'?
udev (162-1) maverick; urgency=low
* New upstream release. Changes since our previous git snapshot:
- cdrom_id: Fix DVD-RW media and blank DVD detection.
- Do not create persistent name rules for kvm/qemu/vmware interfaces.
(LP: #341006)
* Add debian/watch.
-- Martin Pitt
** Branch linked: lp:~ubuntu-core-dev/ubuntu/maverick/udev/ubuntu
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Branch linked: lp:ubuntu/udev
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
This has recently been discussed in #udev, and we found that it does not
hurt that much to blacklist them. The kernel reliably sorts eth*
enumeration by bus number, so as long as you only have cards from one
vendor (or more precisely, drivers), the enumeration will be stable.
Having cards from
Fixed KVM MAC address range:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=c03180194cb62cda286efcc1563391a1408394ff
Added VMWare MACs:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d4de0a0321b471e9dd8c32f1f3266b0b466457c7
** Changed in: udev (Ubuntu)
FWIW Debian has ignored VMware virtual interfaces by mac:
If you grab
http://ftp.us.debian.org/debian/pool/main/u/udev/udev_157-1_i386.deb and
look at lib/udev/rules.d/70-persistent-net-generator.rules it has:
# ignore interfaces with locally administered or null MAC addresses
# and VMWare
I moved this out of incomplete and into triaged. I think everyone here
understands the nature of the problem.
** Changed in: udev (Ubuntu)
Status: Incomplete = Triaged
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received
Just confirming that this also occurs on a KVM virtual machine, in my
case I was using 'virt-clone' to clone a system, which changes the MAC
addr... on boot of the clone you have eth0 moved to eth1 due to the
persistent udev rule entries.
--
ease cloning of virtual images by disabling mac
PCI based addressing ought to work, although this would break the
(admittedly rather theoretical) possibility to move them to a different
slot, etc. For hotpluggable network cards (USB etc, as you might find
them on e. g. the Beagle board or other embedded controllers) we must
stay at MAC-based
Just my two cents here:
I ran into this issue last week. I was attempting to clone a virtual
machine on a remote server to create a new VM. The lag between my
location and the server is big enough to make doing installations
remotely a pain, but the commandline clone functionality is superb.
On Thu, 11 Feb 2010, Martin Pitt wrote:
PCI based addressing ought to work, although this would break the
(admittedly rather theoretical) possibility to move them to a different
slot, etc. For hotpluggable network cards (USB etc, as you might find
them on e. g. the Beagle board or other
http://hg.fedorahosted.org/hg/python-virtinst/file/ae6ca033e8c5/virtinst/util.py#l181
indicates that:
- 00:16:3E allocated to xensource
- 52:54:00 used by qemu/kvm
http://libvirt.org/drvesx.html indicates:
- 00:0c:29 and 00:50:56 are owned by vmware
Further, I know that
- d0-0d used by
I just re-read the above and see that xen devices are currently ignored.
Given that, I do think it makes sense to also handle vmware (and
possibly even virtio devices the same way).
That said, we don't want xen, vmware, or any systems with multiple
network interfaces to give non-deterministic
The bug here is really no different than if you have a real server,
and need to change the network card. You'd stop the server, replace the
card, start the server and no longer have eth0.
There are a number of things that really *should* be done when
cleaning an image, this is just one of them.
Thanks for the explanation, Matthew.
Seems we are between a rock and a hard place here -- we should not break
setups with multiple interfaces, but this is indeed an inconvenience,
too. The current udev rules already ignores xen devices, that would
speak for ignoring VMWare as well for
Thanks for the explanation, Matthew.
Seems we are between a rock and a hard place here -- we should not break
setups with multiple interfaces, but this is indeed an inconvenience,
too. The current udev rules already ignores xen devices, that would
speak for ignoring VMWare as well for
Thanks for the explanation, Matthew.
Seems we are between a rock and a hard place here -- we should not break
setups with multiple interfaces, but this is indeed an inconvenience,
too. The current udev rules already ignores xen devices, that would
speak for ignoring VMWare as well for
Is there any way that udev could see that although the mac address has
changed, the device (PCI device 0x8086:0x100f (e1000)) is the same, so
modify the existing rule instead of creating a new one?
--
ease cloning of virtual images by disabling mac address rules
** Changed in: udev (Ubuntu)
Assignee: Martin Pitt (pitti) = (unassigned)
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
http://coffer.com/mac_find/?string=vmware confirms these two vendor
prefixes from VMWare (and two more).
However, I still don't quite understand why merely blacklisting that
vendor will help/won't break anything. What about VMs with more than one
NIC? Such as a virtualized firewall? They
Likewise, if a cloned instance gets a new MAC, then the generated rule
in /etc/udev/rules.d/70-persistent-net.rules won't match, and thus
should be equivalent to not existing at all.
I'm trying to understand what breaks here, and why the blacklisting
would help with that.
--
ease cloning of
I hadn't considered vms with multiple nics and having them enumerated
correctly might be worth more than fixing this issue.
On an existing vm with one interface, /etc/udev/rules.d/70-persistent-
net.rules might be something like:
# PCI device 0x8086:0x100f (e1000)
SUBSYSTEM ...
Attaching ubuntu-bug udev from a vmware virtual machine.
I'm not sure if the virtual nics appear to the OS as any different from
the actual hardware they are emulating, but I do know all virtual NICs
inside vmware vms have MAC addresses starting with 00:0c:29 or 00:50:56.
I think everyone who
Please supply the requested information
** Changed in: udev (Ubuntu)
Status: Incomplete = Invalid
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received this bug notification because you are a member of Ubuntu
Bugs, which is
What are these devices?
Are they the MAC address of the emulated vmware interface, or the MAC
address of the host-side interface?
** Changed in: udev (Ubuntu)
Importance: Undecided = Wishlist
Status: New = Incomplete
--
ease cloning of virtual images by disabling mac address rules
Hi,
this is for the emulated NICs inside the image - in this case vmware, but AFAIK
it works in the same way for xen, virtualbox and maybe kvm.
--
ease cloning of virtual images by disabling mac address rules
https://bugs.launchpad.net/bugs/341006
You received this bug notification because you
31 matches
Mail list logo
