On 4/18/20 3:25 PM, Martin Kletzander wrote:
On Thu, Apr 16, 2020 at 11:57:45AM -0400, Mark Asselstine wrote:
It is possible and common to rename some devices, this is especially
true for ethernet devices such as veth pairs.
In the udevEventHandleThread() we will be notified of this change but
currently we only process "add", "change" and "remove"
events. Renaming a device such as above results in a "move" event, not
a "remove" followed by and "add" or vise versa. This change will add
the new/destination device to our records but unfortunately there is
no usable mechanism to identify the old/source device to remove it
from the records. So this is admittedly only a partial fix.
There is, but it is only internal. We should ask for the function
`udev_device_get_devpath_old()` to be publicized, if possible. That
should give
us the old name.
I know we talked about this during weekend and I've found a way. I will
post the patches once these are merged.
When I checked this using `udevadm monitor --property` I got two events
for each
rename, one kernel event (where the old path pointed to the previous
name) and
one udev event where the old path referred to the original name the
device was
created with.
For example when I created a virtual network device with the name
"fdsa", then
renamed it bunch of times, started udev monitoring and then renamed it from
"first" to "second" this was the output of udevadm for that one
particular rename:
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[36343.246068] move /devices/virtual/net/second (net)
ACTION=move
DEVPATH=/devices/virtual/net/second
DEVPATH_OLD=/devices/virtual/net/first
IFINDEX=3
INTERFACE=second
SEQNUM=4609
SUBSYSTEM=net
UDEV [36343.246785] move /devices/virtual/net/fdsa (net)
ACTION=move
DEVPATH=/devices/virtual/net/fdsa
DEVPATH_OLD=/devices/virtual/net/first
IFINDEX=3
INTERFACE=fdsa
SEQNUM=4609
SUBSYSTEM=net
USEC_INITIALIZED=136864589
Problem is, UDEV doesn't update INTERFACE (which is where libvirt gets
the ifname from) when net.ifnames is present. This then leads to all
kinds of subsequent troubles like inability to query the interface
address, etc. But if we'd use KERNEL as the source then we would see
updated ifnames.
Reviewed-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
Michal
