yahoo-eng-team team mailing list archive

[David Britton <david.britton@xxxxxxxxxxxxx>]

There is an SRU in progress

[ubuntu/xenial-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.04.2 (Waiting for approval)
[ubuntu/yakkety-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~16.10.2 (Waiting for approval)
[ubuntu/zesty-proposed] cloud-init 0.7.9-153-g16a7302f-0ubuntu1~17.04.2 (Waiting for approval)

That will address the blocking portion of this bug.  The interfaces will
not be bonded, but the instance will boot with basic networking and
allow anyone to bond the interfaces as a post-boot step however they
would like.

A more advanced solution will be proposed.


** Also affects: cloud-init
   Importance: Undecided
       Status: New

** No longer affects: udev (Ubuntu)

** Changed in: cloud-init
   Importance: Undecided => High

** Summary changed:

- [Hyper-V] VF renaming on Azure
+ [Hyper-V] Advanced networking support on Azure

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1690430

Title:
  [Hyper-V] Advanced networking support on Azure

Status in cloud-init:
  New

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/cloud-init/+bug/1690430/+subscriptions