Yes, that would probably do just fine. Raring is using the 3.8 kernel,
yes? I have been building 3.8 kernels for some of my 12.04 deploys, and
with few exceptions it has worked well, as it has the necessary fix. So,
if Raring is on 3.8, the enablement stack would work for me. Thanks!
-- Matthew
On Fri, Jan 3, 2014 at 1:13 PM, Christopher M. Penalver <
<email address hidden>> wrote:
> liquidhorse, would utilizing the Raring enablement stack in Precise via
> https://wiki.ubuntu.com/Kernel/LTSEnablementStack work for you?
>
> ** Changed in: linux (Ubuntu)
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1098302
>
> Title:
> Bonding mode Balance-ALB stomps VM MACs
>
> Status in “linux” package in Ubuntu:
> Incomplete
>
> Bug description:
> This issue was fixed in the 3.8 kernel series; I have backported the
> appropriate patch (as directed by the netdev kernel list) to the 3.0
> kernel and it worked successfully on several machines. I have built
> but NOT tested this patch against 3.2 and 3.4 kernels. The patch
> appears to require minor modification for inclusion in the 3.7 kernel
> series. The issue resolved is as follows:
>
> This issue affects (at the least) virtual machines running under KVM
> and using bridging to connect to a network, when that bridge
> communicates over a bond using mode-6 (balance-alb). To replicate,
> configure a bond of 1 or more adapters with mode-6 and bridge over
> that bond. Configure a virtual machine (in my instance, I used KVM)
> to place its vnet adapter under the same bridge. With the VM running,
> ping the virtual machine from a remote host and check the ARP cache on
> the remote host. You will find that the MAC reported for the virtual
> machine will not be its configured MAC, but the MAC of one of the
> bond's slaves. This causes intermittent and significant connectivity
> losses (both to and from the virtual machine).
>
> The patch modifies the balance-alb bonding driver to leave non-local
> MACs unmodified. After application, a repeat of the above test should
> result in the virtual machine's correct MAC being reported in the ARP
> cache of the remote host.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1098302/+subscriptions
>
Yes, that would probably do just fine. Raring is using the 3.8 kernel,
yes? I have been building 3.8 kernels for some of my 12.04 deploys, and
with few exceptions it has worked well, as it has the necessary fix. So,
if Raring is on 3.8, the enablement stack would work for me. Thanks!
-- Matthew
On Fri, Jan 3, 2014 at 1:13 PM, Christopher M. Penalver <
<email address hidden>> wrote:
> liquidhorse, would utilizing the Raring enablement stack in Precise via /wiki.ubuntu. com/Kernel/ LTSEnablementSt ack work for you? /bugs.launchpad .net/bugs/ 1098302 /bugs.launchpad .net/ubuntu/ +source/ linux/+ bug/1098302/ +subscriptions
> https:/
>
> ** Changed in: linux (Ubuntu)
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Bonding mode Balance-ALB stomps VM MACs
>
> Status in “linux” package in Ubuntu:
> Incomplete
>
> Bug description:
> This issue was fixed in the 3.8 kernel series; I have backported the
> appropriate patch (as directed by the netdev kernel list) to the 3.0
> kernel and it worked successfully on several machines. I have built
> but NOT tested this patch against 3.2 and 3.4 kernels. The patch
> appears to require minor modification for inclusion in the 3.7 kernel
> series. The issue resolved is as follows:
>
> This issue affects (at the least) virtual machines running under KVM
> and using bridging to connect to a network, when that bridge
> communicates over a bond using mode-6 (balance-alb). To replicate,
> configure a bond of 1 or more adapters with mode-6 and bridge over
> that bond. Configure a virtual machine (in my instance, I used KVM)
> to place its vnet adapter under the same bridge. With the VM running,
> ping the virtual machine from a remote host and check the ARP cache on
> the remote host. You will find that the MAC reported for the virtual
> machine will not be its configured MAC, but the MAC of one of the
> bond's slaves. This causes intermittent and significant connectivity
> losses (both to and from the virtual machine).
>
> The patch modifies the balance-alb bonding driver to leave non-local
> MACs unmodified. After application, a repeat of the above test should
> result in the virtual machine's correct MAC being reported in the ARP
> cache of the remote host.
>
> To manage notifications about this bug go to:
> https:/
>