From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id CBF982C37 for ; Thu, 2 Feb 2017 18:10:36 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 377853D955; Thu, 2 Feb 2017 17:10:37 +0000 (UTC) Received: from redhat.com (ovpn-117-166.ams2.redhat.com [10.36.117.166]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v12HATaw003679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Feb 2017 12:10:32 -0500 Date: Thu, 2 Feb 2017 17:10:28 +0000 From: "Daniel P. Berrange" To: "Michael S. Tsirkin" Cc: Maxime Coquelin , Michal Privoznik , Kevin Traynor , Ciara Loftus , mark.b.kavanagh@intel.com, Flavio Leitner , Yuanhan Liu , Daniele Di Proietto , "dev@openvswitch.org" , "dev@dpdk.org" , "libvir-list@redhat.com" Message-ID: <20170202171028.GT2915@redhat.com> References: <20170201094304.GA3232@redhat.com> <20170201114119.GE3232@redhat.com> <20170202150621.GQ2915@redhat.com> <20170202181827-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170202181827-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 02 Feb 2017 17:10:37 +0000 (UTC) Subject: Re: [dpdk-dev] [libvirt] [RFC] Vhost-user backends cross-version migration support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Daniel P. Berrange" List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 17:10:37 -0000 On Thu, Feb 02, 2017 at 06:21:55PM +0200, Michael S. Tsirkin wrote: > On Thu, Feb 02, 2017 at 03:06:21PM +0000, Daniel P. Berrange wrote: > > On Thu, Feb 02, 2017 at 03:14:01PM +0100, Maxime Coquelin wrote: > > > > > > > > > On 02/01/2017 12:41 PM, Daniel P. Berrange wrote: > > > > > > > > It depends where / how in OVS it needs to be set. The only stuff libvirt > > > > does with OVS is to run 'add-port' and 'del-port' commands via the ovs > > > > cli tool. We pass through arguments from the port profile stored in the > > > > XML config. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eg those things in get passed as cli args to the 'add-port' > > > > command. Soo if add-port needs this new version string, then we'd need > > > > to add the version to the openvswitch virtualport XML. > > > > > > > > If the version is provided to OVS in a different command, then it would > > > > probably be outside scope of libvirt. > > > > > > I think it would make sense to be a parameter of the add-port command. > > > But it would be for vhost-user related add-port command, I didn't find > > > where/if this is managed in libvirt XML. > > > > For vhost-user, libvirt does not have any interaction with OVS at > > all. If the thing that's using the vhost-user UNIX socket, in turn > > connects to OVS, that's outside scope of libvirt. IOW, for vhost-user > > OVS it seems like that job is for Nova / os-vif to solve. > > I don't think they currently understand the issues involved in > cross-version migration though. This is a complex subject and easy to > get wrong. It would be significantly better to figure it out at libvirt > level since it already deals with cross-version migration issues. Libvirt considers vhost-user to be a blackbox though - it just exposes a UNIX socket, and whatever is on the other end is completely opaque. The fact that the other end might plumb the data stream into openvswitch is not something libvirt should know, as we don't want to end up having to add custom code to libvirt for every different vhost-user server impl. IOW, if the version str can be passed to QEMU, and then onto vhost-user backend in QEMU, then libvirt can be involved. If the version str has to be given to openvswitch that's not for libvirt to deall with. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|