[Bug 1690430] Re: [Hyper-V] VF renaming on Azure
David Britton
david.britton at canonical.com
Fri Jun 16 13:49:59 UTC 2017
** Changed in: udev (Ubuntu)
Importance: Undecided => High
** Changed in: udev (Ubuntu)
Status: New => Triaged
** Changed in: udev (Ubuntu)
Status: Triaged => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to udev in Ubuntu.
https://bugs.launchpad.net/bugs/1690430
Title:
[Hyper-V] VF renaming on Azure
Status in udev package in Ubuntu:
Confirmed
Bug description:
We are in the process of rolling out SR-IOV in Azure (available as a
preview now, contact me offline and we can work out getting your
subscription addedif you want to try it). In general our normal
synthetic interface appears as eth0 and the VF comes in as eth1. We
intend to bond these interfaces together so that if the VF goes down,
or the VM is migrated to where no VF is present, eth0 remains as the
valid default interface.
At the moment we are handling the bonding via this script:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/plain/tools/hv/bondvf.sh
We were looking at ways to either integrate the behavior into cloud-
init or invoke the script from cloud-init and do the right thing.
We recently observed after https://bugs.launchpad.net/ubuntu/+source
/cloud-init/+bug/1669860 that the VF interface gets renamed to
something like "enP1p0s2" but more recently as "rename2".
Is it possible that 1669860 needs to be expanded to cover our case or
is there something we should be doing to make sure that change is
working properly for SR-IOV in Azure?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1690430/+subscriptions
More information about the foundations-bugs
mailing list