Bug 1477559 - Migration supported for cross-backend network
Migration supported for cross-backend network
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Amnon Ilan
xianwang
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-02 07:48 EDT by xianwang
Modified: 2017-08-14 06:53 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description xianwang 2017-08-02 07:48:23 EDT
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 08:05:23 EDT
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 08:10:54 EDT
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 06:13:07 EDT
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 08:31:08 EDT
(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 08:57:50 EDT
(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 14:04:28 EDT
(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-09 23:08:02 EDT
(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 01:37:04 EDT
(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.