RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 553337 - [LTC 6.0 FEAT] VEPA support [202042] -- macvtap driver
Summary: [LTC 6.0 FEAT] VEPA support [202042] -- macvtap driver
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: All
high
high
Target Milestone: rc
: 6.0
Assignee: Anthony Liguori
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 356741 532549 553348 554559
TreeView+ depends on / blocked
 
Reported: 2010-01-07 16:40 UTC by IBM Bug Proxy
Modified: 2014-07-25 03:06 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-11 15:43:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
macvtap device driver, backported to 2.6.32+macvlan changes (24.34 KB, text/plain)
2010-01-07 16:40 UTC, IBM Bug Proxy 		no flags Details
update to currently pending upstream version (3.46 KB, text/plain)
2010-02-11 16:15 UTC, IBM Bug Proxy 		no flags Details
20d29d7a9 net: macvtap driver (18.91 KB, text/plain)
2010-02-19 15:11 UTC, IBM Bug Proxy 		no flags Details
564517e804c9c6d4e net/macvtap: fix reference counting (4.45 KB, text/plain)
2010-02-19 15:11 UTC, IBM Bug Proxy 		no flags Details
02df55d28c macvtap: rework object lifetime rules (10.90 KB, text/plain)
2010-02-19 15:21 UTC, IBM Bug Proxy 		no flags Details
b9fb9ee07e macvtap: add GSO/csum offload support (8.87 KB, text/plain)
2010-02-19 15:21 UTC, IBM Bug Proxy 		no flags Details
501c774cb net/macvtap: add vhost support (7.76 KB, text/plain)
2010-02-19 15:21 UTC, IBM Bug Proxy 		no flags Details
Patch set with conflicts fixed (13.66 KB, application/x-gzip)
2010-03-20 02:07 UTC, Anthony Liguori 		no flags Details
patch to bring previous series (52130) in line with mainline (6.22 KB, text/plain)
2010-03-22 13:42 UTC, IBM Bug Proxy 		no flags Details
all previous patches in order (15.26 KB, application/x-compressed-tar)
2010-03-22 13:51 UTC, IBM Bug Proxy 		no flags Details
Show Obsolete (7) View All


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 58946 0 None None None Never

Description IBM Bug Proxy 2010-01-07 16:40:48 UTC 
=Comment: #0=================================================
Arnd Bergmann <arnd.bergmann.com> - 
+++ This bug was initially created as a clone of Bug #57504 +++

1. Feature Overview:
Feature Id:	[202042]
a. Name of Feature:	VEPA support
b. Feature Description
The VEPA/PEPA support defers all switching and access control to the external fabric switches
thereby simplifying the management and control at layer 2.

2. Feature Details:
Sponsor:	LTC
Architectures:
x86
x86_64

Arch Specificity: Both
Affects Kernel Modules: Yes
Delivery Mechanism: Direct from community
Category:	Xen
Request Type:	Kernel - Enhancement from Upstream
d. Upstream Acceptance:	In Progress
Sponsor Priority	1
f. Severity: High
IBM Confidential:	no
Code Contribution:	IBM code
g. Component Version Target:	2.6.33

3. Business Case
In data center/cloud environments with a large number of VMs and  a large network fabric the
configuration and management of the network needs to be simplified and automated.

4. Primary contact at Red Hat: 
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Albert Kopp, AKOPP.com

Technical contact(s):

Vivek Kashyap, vivk.com

IBM Manager:
Christoph Arenz, arenz.com
=Comment: #1=================================================
Arnd Bergmann <arnd.bergmann.com> - 
The macvtap driver did not make the 2.6.33 merge window, unlike the base VEPA support in macvlan.

This item is lower priority compared to the code that was merged iff we have the raw backend in
qemu, but it would still be helpful to include it.
=Comment: #2=================================================
ANTHONY N. LIGUORI <aliguori.com> - 
The raw backend won't be merged into upstream qemu.  For 0.13, I think we're going to attempt to
overhaul the network infrastructure to support two types of file descriptors, ones that implement a
vhost-style interface and one that implements a read/write interface (with an optional vhost-net
header).  We'll then have a pluggable mechanism for creating those file descriptors.

I don't think this will be in place for a few months and it's likely to be invasive.  I think
macvtap is the best option for RHEL6.
=Comment: #3=================================================
Arnd Bergmann <arnd.bergmann.com> - 

macvtap device driver, backported to 2.6.32+macvlan changes

This is the current state of the macvtap driver, which has not yet been merged upstream. I will
resubmit this in the next days for inclusion in net-next for 2.6.34.
Comment 1 IBM Bug Proxy 2010-01-07 16:40:56 UTC 
Created attachment 382278 [details]
macvtap device driver, backported to 2.6.32+macvlan changes
Comment 3 John Jarvis 2010-01-07 17:27:04 UTC 
IBM is signed up to test and provide feedback.
Comment 8 IBM Bug Proxy 2010-02-11 16:15:36 UTC 
Created attachment 390286 [details]
update to currently pending upstream version


------- Comment on attachment From arnd.bergmann.com 2010-02-11 11:03 EDT-------


This patch should get applied on top of the previous patch in order to fix all known bugs.
Comment 11 Anthony Liguori 2010-02-18 02:52:55 UTC 
Arnd,

What's the upstream status of this patch?  Has it been accepted into net-next?  If so, please attach the version of the patch(es) in net-next along with the Signed-off-by/Acked-by's that they have accumulated.

The current patches attached have no commit messages/Signed-off-by's associated with them.
Comment 12 IBM Bug Proxy 2010-02-19 13:31:11 UTC 
------- Comment From arnd.bergmann.com 2010-02-19 08:24 EDT-------
(From update of attachment 51189 [details])
add changeset comment including all headers for attachment 51189 [details]

------- Comment From arnd.bergmann.com 2010-02-19 08:26 EDT-------
(From update of attachment 51189 [details])
add changeset comment including all headers for attachment 51189 [details]
Comment 13 IBM Bug Proxy 2010-02-19 15:11:35 UTC 
Created attachment 395117 [details]
20d29d7a9 net: macvtap driver


------- Comment on attachment From arnd.bergmann.com 2010-02-19 10:08 EDT-------


patch from http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=commitdiff;h=32499fbb16334765882d727946f66000e9b262b6

upstream ID: 20d29d7a916a47bf533b5709437fe735b6b5b79e
Comment 14 IBM Bug Proxy 2010-02-19 15:11:40 UTC 
Created attachment 395118 [details]
564517e804c9c6d4e net/macvtap: fix reference counting
Comment 15 IBM Bug Proxy 2010-02-19 15:21:32 UTC 
------- Comment From arnd.bergmann.com 2010-02-19 10:16 EDT-------
Added the complete set of five patches separately, as they are now on git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git#macvlan-2.6.32 .

Each patch corresponds directly to one patch in the upstream kernel, as referenced by the oneline patch description. Please tell me if this is not the ideal way to do it.
Comment 16 IBM Bug Proxy 2010-02-19 15:21:40 UTC 
Created attachment 395121 [details]
02df55d28c macvtap: rework object lifetime rules


------- Comment on attachment From arnd.bergmann.com 2010-02-19 10:12 EDT-------


from http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=commitdiff;h=36552f0fd874f1d8196a90df24c6f34bf28d94a1
Comment 17 IBM Bug Proxy 2010-02-19 15:21:44 UTC 
Created attachment 395122 [details]
b9fb9ee07e macvtap: add GSO/csum offload support


------- Comment on attachment From arnd.bergmann.com 2010-02-19 10:13 EDT-------


http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=commitdiff;h=57c4bdb76002bb97aed001b61200f4e69fd1928b
Comment 18 IBM Bug Proxy 2010-02-19 15:21:49 UTC 
Created attachment 395123 [details]
501c774cb net/macvtap: add vhost support


------- Comment on attachment From arnd.bergmann.com 2010-02-19 10:14 EDT-------


http://git.kernel.org/?p=linux/kernel/git/arnd/playground.git;a=commitdiff;h=6f9702f1067726ca5ccbd23a219b1d4136b65ce3
Comment 19 IBM Bug Proxy 2010-02-23 15:51:31 UTC 
------- Comment From arnd.bergmann.com 2010-02-23 10:47 EDT-------
Please note that the final patch "501c774cb net/macvtap: add vhost support" also has a dependency on the vhost-net driver that is reflected in a different feature and contains code from Michael Tsirkin.
I backported the upstream version of that code to 2.6.32 myself, in order to generate the patch in this series.

Let me know if this patch does not cleanly apply on the backport done for the RHEL kernel and if you need help porting it to that version.
Comment 20 Anthony Liguori 2010-03-20 02:07:40 UTC 
Created attachment 401384 [details]
Patch set with conflicts fixed

This set of patches conflicted with the macvlan patches in #566731 in that some of the structures defined in include/linux/if_macvlan.h are also defined in drivers/net/macvlan.c.

To resolve this, I made the macvtap patch that introduced these structures into if_macvlan.h remove the structures from macvlan.c.  That also involved changing the visibility of a few functions that macvtap depends on and removing a duplicate definition of a static inline.
Comment 21 Anthony Liguori 2010-03-20 02:08:25 UTC 
These patches have been submitted to the RH kernel mailing list for review
Comment 22 IBM Bug Proxy 2010-03-22 13:01:51 UTC 
------- Comment From arnd.bergmann.com 2010-03-22 08:50 EDT-------
(In reply to comment #22)

> To resolve this, I made the macvtap patch that introduced these structures into
> if_macvlan.h remove the structures from macvlan.c.  That also involved changing
> the visibility of a few functions that macvtap depends on and removing a
> duplicate definition of a static inline.

Sorry about this, it appears that I accidentally dropped the backport of changeset fc0663d6
"macvlan: allow multiple driver backends" when I was splitting up the series. I'll redo my git tree and attach the correct version.
Comment 23 IBM Bug Proxy 2010-03-22 13:42:13 UTC 
Created attachment 401763 [details]
patch to bring previous series (52130) in line with mainline


------- Comment on attachment From arnd.bergmann.com 2010-03-22 09:39 EDT-------


This patch is a cherry-pick of fc0663d6b "macvlan: allow multiple driver backends" on top of the 52130 patch series, which should make macvtap operation work again. This patch was originally missing from the series. I'm attaching it for reference here, you could either apply this one on top, or take the whole series from my git, as posted in the next series.
Comment 24 IBM Bug Proxy 2010-03-22 13:51:54 UTC 
Created attachment 401768 [details]
all previous patches in order


------- Comment on attachment From arnd.bergmann.com 2010-03-22 09:48 EDT-------


This is the combined version of Anthony's tarball and my fix, with the correct attribution of the upstream patches.

Compared with 51401..51405, it adds the config file change from 52130 and a backport of the missing upstream patch (fc0663d6b).

The code with this series applied should be identical to all of 52130 plus the  52145 patch.
Comment 25 IBM Bug Proxy 2010-03-22 15:32:11 UTC 
------- Comment From aliguori.com 2010-03-22 11:08 EDT-------
Instead of rebasing the series, can you add patches on top of the series I posted and then point me to those?
Comment 26 IBM Bug Proxy 2010-03-22 17:32:51 UTC 
------- Comment From arnd.bergmann.com 2010-03-22 13:26 EDT-------
(In reply to comment #26)
> Instead of rebasing the series, can you add patches on top of the series I
> posted and then point me to those?

See attachment 52145 [details] for that, sorry if the description wasn't clear enough.
Comment 27 Anthony Liguori 2010-03-25 16:51:56 UTC 
Arnd, can you post some instructions for testing macvtap with qemu-kvm?
Comment 28 IBM Bug Proxy 2010-03-26 10:21:31 UTC 
------- Comment From arnd.bergmann.com 2010-03-26 06:14 EDT-------
(In reply to comment #28)
> Arnd, can you post some instructions for testing macvtap with qemu-kvm?

To manually set up a macvtap device, use the 'ip link add link <dev> dev macvtap0 type macvtap' command, where <dev> is the ethernet interface you want to connect to, typically eth0. 'ip link show' gives you a list of device names and interface indexes. With a default udev setup, the new tap device is now /dev/tap%d, where %d is the index of the newly created macvtap0 device.

It is important that the mac address of the guest matches the mac address of the macvtap device, so set that address using 'ifconfig macvtap0 hw ether <mac>' or read the mac address from the macvtap device for passing it to qemu-kvm.

Further, make sure that both the underlying device <dev> and the macvtap device are 'up'.

To start qemu-kvm, you need to pass the open /dev/tap%d character device as a file descriptor. From a bash command prompt, you can do that using the <> redirect operator, e.g.

qemu-kvm -net tap,fd=3 -net nic,model=virtio,macaddr=ea:f3:fc:99:c6:aa 3<> /dev/tap7
Comment 29 IBM Bug Proxy 2010-03-26 11:31:22 UTC 
------- Comment From gerhard.stenzel.com 2010-03-26 07:20 EDT-------
And if you have a libvirt with macvtap support, add something like the following to the domain.xml:

...
<devices>
<interface type='direct'>
<source dev='eth1' mode='vepa'/>
</interface>
</devices>
...
Comment 32 IBM Bug Proxy 2010-05-11 11:21:37 UTC 
------- Comment From gerhard.stenzel.com 2010-05-11 07:19 EDT-------
I verified RHEL 6.0 snap 1 contains kernel 2.6.32-22 and the macvtap module is included
Comment 33 Miya Chen 2010-08-11 09:56:19 UTC 
test with 2.6.32-59.el6.x86_64
1.
# lsmod |grep macvtap
macvtap                 7867  3 vhost_net
macvlan                 9986  1 macvtap

2. set up macvtap
# ip link add link eth0 dev macvtap0 type macvtap
# ip link set macvtap0 address 1a:46:0b:ca:bc:7b up
# ip link show macvtap0
3: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UNKNOWN qlen 500
    link/ether 1a:46:0b:ca:bc:7b brd ff:ff:ff:ff:ff:ff

3. Boot up guest with macvtap0 that have been created, guest network works fine:
# /usr/libexec/qemu-kvm -m 2G -smp 2 -drive file=/home/RHEL-Server-6.0-64-virtio.qcow2,if=none,id=test,boot=on,cache=none,format=qcvice virtio-blk-pci,drive=test -monitor stdio -netdev tap,id=hostnet0,vhost=on,fd=3 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=1a:46:0b:ca:bc:7b 3<>/dev/tap3 -vnc :9
Comment 34 releng-rhel@redhat.com 2010-11-11 15:43:32 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.