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 16CD32BCD for ; Fri, 3 Feb 2017 16:55:04 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70F054E34D; Fri, 3 Feb 2017 15:55:04 +0000 (UTC) Received: from redhat.com (ovpn-117-145.ams2.redhat.com [10.36.117.145]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A8362B3249; Fri, 3 Feb 2017 15:54:57 +0000 (UTC) Date: Fri, 3 Feb 2017 15:54:52 +0000 From: "Daniel P. Berrange" To: "Michael S. Tsirkin" Cc: Maxime Coquelin , Ciara Loftus , mark.b.kavanagh@intel.com, Flavio Leitner , Daniele Di Proietto , "dev@openvswitch.org" , Kevin Traynor , Yuanhan Liu , "dev@dpdk.org" , "libvir-list@redhat.com" , sean.k.mooney@intel.com Message-ID: <20170203155452.GL10350@redhat.com> References: <4cad5796-7024-4a48-a73a-8dd780259968@redhat.com> <20170203172140-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170203172140-mutt-send-email-mst@kernel.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 03 Feb 2017 15:55:04 +0000 (UTC) Subject: Re: [dpdk-dev] [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: Fri, 03 Feb 2017 15:55:04 -0000 On Fri, Feb 03, 2017 at 05:34:07PM +0200, Michael S. Tsirkin wrote: > On Fri, Feb 03, 2017 at 03:11:10PM +0100, Maxime Coquelin wrote: > > Hi, > > > > On 02/01/2017 09:35 AM, Maxime Coquelin wrote: > > > Hi, > > > > > > Few months ago, Michael reported a problem about migrating VMs relying > > > on vhost-user between hosts supporting different backend versions: > > > - Message-Id: <20161011173526-mutt-send-email-mst@kernel.org> > > > - https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg03026.html > > > > > > The goal of this thread is to draft a proposal based on the outcomes > > > of discussions with contributors of the different parties (DPDK/OVS > > > /libvirt/...). > > > > Thanks the first feedback. It seems to converge that this is Nova's > > role, but not Libvirt one to manage these versions from management tool > > layer. > > > I think the conclusion is not that it should go up the stack. I think > this will just get broken all the time. No one understands versions and > stuff. Even QEMU developers get confused and break compatibility once in > a while. I don't think it is really true, nor is it really specific to migration, it can hit any time you have a network connection that is re-opened even without migration. Version compatibility negotiations are an inherant part of any network protocol that is expected to evolve over time. > My conclusion is that doing it from OVS side is wrong. Migration is not > an OVS thing, it's a QEMU thing, and libvirt abstracts QEMU. People > just want migration to work, ok? It's our job to do it, we do not really > need a "make things work" flag. > > If libvirt does not want to use the vhost-user protocol (which sounds > reasonable, it's rather complex) how about qemu providing a small > utility to query the port? We could output json or whatever. > > This can help with MTU as well. > > And maybe it will help with nowait support - if someone uses the utility > to dump backend config once, QEMU can later start the device without > feature queries. I don't think it is QEMU's job to deal with external components in this way and don't think QEMU vhost-user should be treated as special. This general scenario arises any time there is a QEMU backend is talking to an external service/process. For example, a virtio-serial talking to a daemon in the host. This daemon can support different versions of the protocol being spoken, so we have the same compat issue on migration. Or a traditional serial device, which the guest is using to talk to an external daemon the host. In a few cases we might know what the protocol is, but in general the data stream is opaque to QEMU. QEMU should not have need to learn about every single protocol that might be used to communicate with some external service. This is an unbounded set of possibilities to deal with, some of which will not even be open source. This all needs to be delegated to whatever mgmt app is responsible for setting up these external services, as it has the right domain knowledge about the applications being used, to make the policy decisions that are suitable for its usage scenario. 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/ :|