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 1477559 - Migration supported for cross-backend network
Summary: Migration supported for cross-backend network
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Amnon Ilan
QA Contact: xianwang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-02 11:48 UTC by xianwang
Modified: 2018-02-01 08:36 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-01-02 15:41:49 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description xianwang 2017-08-02 11:48:23 UTC 
Description of problem:

1)This bug is to confirm whether migration supported for cross-backend network, whether the following scenarios are legal:

tap <-> tap
macvtap <-> macvtap
macvtap <-> tap
openvswitch <-> openvswitch
tap <-> openvswitch

2)For legal scenarios, what are the priorities for them?

3)The qemu cli for them:
3.1)tap:
    -netdev tap,id=hostnet0,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4 \

3.2)macvtap:
    -netdev tap,id=hostnet0,vhost=on,fds=6:7:8:9 \
    -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:c1:97:c3,bus=pci.0,addr=0x4,mq=on 6<>/dev/tap6 7<>/dev/tap6 8<>/dev/tap6 9<>/dev/tap6 \

configure macvtap method:
# ip link add link eno1 name brg_macvtap type macvtap mode bridge
# ip link set brg_macvtap up
# ip link show

....
69: brg_macvtap@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT qlen 500
link/ether c2:54:bb:58:b9:d2 brd ff:ff:ff:ff:ff:ff

qemu command line:

-netdev tap,id=hostnet0,vhost=on,fd=9 
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=c2:54:bb:58:b9:d2 9<>/dev/tap69



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 xianwang 2017-08-02 12:05:23 UTC 
Sorry, it seems I misunderstand them, after reviewing the virtual network test plan, the concept should be as following:

1)For tun/tap backend (bridge-utils based & openvswitch based)
-device virtio-net-pci,netdev=dev1,mac=9a:e8:e9:ea:eb:ec,id=net1 \
-netdev tap,id=dev1,vhost=on,script=/etc/ifup_script,
downscript=/etc/ifdown_script,ifname=guest1 \

2)For macvtap backend
-device virtio-net-pci,netdev=dev1,mac=$mac_macvtap_interface,id=net1
$fd<>/dev/$tap \
-netdev tap,id=dev1,fd=$fd,vhost=on \

So, it seems there is only two bankends for network, yvugenfi, could you confirm whether the above understanding is right? 

And, for bug description, from the network point of view, could you give confirmation which scenarios are legal for cross-backend migraion?  Thanks!
Comment 3 xianwang 2017-08-02 12:10:54 UTC 
For the following test matrix for migration, I will make it referring to this bug to avoid to miss any scenario, so, it's great to get your developers' confirmation.
Thanks!
Comment 5 jason wang 2017-08-09 10:13:07 UTC 
We should support cross backend migration between any kind of following backends:

- tap, vhost=on
- tap, vhost=off
- macvtap, vhost=on
- macvtap, vhost=off
- vhost-user

Thanks
Comment 6 Amnon Ilan 2017-08-09 12:31:08 UTC 
(In reply to jason wang from comment #5)
> We should support cross backend migration between any kind of following
> backends:
> 
> - tap, vhost=on
> - tap, vhost=off
> - macvtap, vhost=on
> - macvtap, vhost=off
> - vhost-user
> 
> Thanks

But for all the above options it should be the same on source and 
destination, right?

And for the vhost-user it get a bit more complex since we need to 
do it for every vhost-user implementation. So far it's only OVS-DPDK 
and we are testing it. In future we may have VPP as well. Both involve 
a more integrative test that relates to to switch in general, where 
vhost-user is just one piece.
Comment 7 jason wang 2017-08-09 12:57:50 UTC 
(In reply to Amnon Ilan from comment #6)
> (In reply to jason wang from comment #5)
> > We should support cross backend migration between any kind of following
> > backends:
> > 
> > - tap, vhost=on
> > - tap, vhost=off
> > - macvtap, vhost=on
> > - macvtap, vhost=off
> > - vhost-user
> > 
> > Thanks
> 
> But for all the above options it should be the same on source and 
> destination, right?

No need to be same for host only part.

> 
> And for the vhost-user it get a bit more complex since we need to 
> do it for every vhost-user implementation. So far it's only OVS-DPDK 
> and we are testing it. In future we may have VPP as well. Both involve 
> a more integrative test that relates to to switch in general, where 
> vhost-user is just one piece.

Yes, but it should succeed unless there's a bug.

Thanks
Comment 8 Dr. David Alan Gilbert 2017-08-09 18:04:28 UTC 
(In reply to jason wang from comment #7)
> (In reply to Amnon Ilan from comment #6)
> > (In reply to jason wang from comment #5)
> > > We should support cross backend migration between any kind of following
> > > backends:
> > > 
> > > - tap, vhost=on
> > > - tap, vhost=off
> > > - macvtap, vhost=on
> > > - macvtap, vhost=off
> > > - vhost-user
> > > 
> > > Thanks
> > 
> > But for all the above options it should be the same on source and 
> > destination, right?
> 
> No need to be same for host only part.
> 
> > 
> > And for the vhost-user it get a bit more complex since we need to 
> > do it for every vhost-user implementation. So far it's only OVS-DPDK 
> > and we are testing it. In future we may have VPP as well. Both involve 
> > a more integrative test that relates to to switch in general, where 
> > vhost-user is just one piece.
> 
> Yes, but it should succeed unless there's a bug.

I didn't think all vhost clients were compatible - I thought some could expose different capabilities; do those capabilities ever reach the guest?
Do they ever reach the migration data?
Comment 9 jason wang 2017-08-10 03:08:02 UTC 
(In reply to Dr. David Alan Gilbert from comment #8)
> (In reply to jason wang from comment #7)
> > (In reply to Amnon Ilan from comment #6)
> > > (In reply to jason wang from comment #5)
> > > > We should support cross backend migration between any kind of following
> > > > backends:
> > > > 
> > > > - tap, vhost=on
> > > > - tap, vhost=off
> > > > - macvtap, vhost=on
> > > > - macvtap, vhost=off
> > > > - vhost-user
> > > > 
> > > > Thanks
> > > 
> > > But for all the above options it should be the same on source and 
> > > destination, right?
> > 
> > No need to be same for host only part.
> > 
> > > 
> > > And for the vhost-user it get a bit more complex since we need to 
> > > do it for every vhost-user implementation. So far it's only OVS-DPDK 
> > > and we are testing it. In future we may have VPP as well. Both involve 
> > > a more integrative test that relates to to switch in general, where 
> > > vhost-user is just one piece.
> > 
> > Yes, but it should succeed unless there's a bug.
> 
> I didn't think all vhost clients were compatible - I thought some could
> expose different capabilities; do those capabilities ever reach the guest?

Yes, but guest visible capability should be kept same between src and dst. This is required for same backend too.

> Do they ever reach the migration data?

For guest visible capability, yes. For host only, not.

Thanks
Comment 10 Qunfang Zhang 2017-08-10 05:37:04 UTC 
(In reply to jason wang from comment #5)
> We should support cross backend migration between any kind of following
> backends:
> 
> - tap, vhost=on
> - tap, vhost=off
> - macvtap, vhost=on
> - macvtap, vhost=off
> - vhost-user
> 
> Thanks

Jason and Dave, 

For cross backend migration, we would only pick up some P1 test cases, it that okay? Since completely test run for all the items in the matrix will be very huge.

Thanks,
Qunfang
Note You need to log in before you can comment on or make changes to this bug.