Dear Frank, fds-dev,
re OPNFV/FDS vhost reconnect requirement that you and team have been
pursuing for OPNFV Colorado 2.0 - on the last CSIT call I got an action to
confirm which negative scenarios you’re actually covering.
Here is my understanding of the three use cases identified to handle
vhost-user-to-virtio (vhost-virtio for short) connectivity disruption at
the data plane level, without involving orchestration stack (libvirt and
above incl. OpenStack) - to keep me honest cc’ing Amnon who is coordinating
with vhost/qemu folks:-
1. vhost reconnect - compatible with virtio1.0 - all shipping VM-based VNFs
a. user-mode vSwitch reboots e.g. crash, upgrade, reload
- vhost backend goes away.
- qemu remembers negotiated virtio features and vring memory region.
- vhost backend comes back.
- qemu reconnects to vhost backend.
b. reconnect is transparent to VM, VM is not aware.
c. reconnect is transparent to the orchestration stack.
2. vhost hot-plug - compatible with virtio1.0 - all shipping VM-based VNFs
a. user-mode vSwitch reboots e.g. crash, upgrade, reload
- vhost backend goes away.
- qemu instructs VM to unload/destroy associated virtio device instance.
- qemu puts the connection into inactive state (new state).
- vhost backend comes back.
- qemu instructs VM to load/create associated virtio device instance -
hot-plug.
- normal negotiation of virtio features takes place.
b. reconnect is not transparent to VM, VM is aware.
c. reconnect is transparent to the orchestration stack.
3. virtio renegotiation - part of new virtio 1.1 spec - will take years to
get assimilated into VM-based VNFs
a. user-mode vSwitch reboots e.g. crash, upgrade, reload
- vhost backend goes away.
- qemu relays vhost backend state to VM virtio driver.
- vhost backend comes back.
- qemu faciliates control channel vhost to VM-virtio.
- negotiation of virtio features takes place vhost to VM-virtio.
b. reconnect is not transparent to VM, VM is aware.
c. reconnect is transparent to the orchestration stack.
I believe what you implementing in OPNFV/FDS based on qemu 2.7, is point 1.
We are discussing point 2. with Redhat and Intel QEMU folks - Damjan and
Pierre are driving this discussion, I'm assisting. Point 3. is about the
proper long-term solution to address 100% of situations in the future.
Points 2. and 3. are tracked in a Monthly DPDK-Virtio meeting coordinated
by Amnon.
-Maciek
Begin forwarded message:
From: Maciek Konstantynowicz <[email protected]<mailto:[email protected]>>
Subject: REMINDER - actions from - csit weekly 161109
Date: 14 November 2016 at 17:50:39 GMT
To: [email protected]<mailto:[email protected]>
http://ircbot.wl.linuxfoundation.org/meetings/fdio-csit/2016/fdio-csit.2016-11-09-15.00.html
Hi, Didn’t see any activity on any of below, so most likely I missed progress.
Could those involved send a quick update by reply-all, with links as applicable.
Action items:
• Maciek to clarify with OPNFV/FDS situation re vhost reconnect
• tfherbert, dwallacelf - Create CentOS VIRL image (CSIT)
• tfherbert, edwarnicke - Create new set of verify jobs with CentOS executor
(CI-MAN)
• tfherbert, pmikus - Create CentOS bootstrap script (CSIT)
-Maciek
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
