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 6CD7D2BE5 for ; Fri, 3 Feb 2017 18:22:15 +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 798D8FAF2D; Fri, 3 Feb 2017 17:22:15 +0000 (UTC) Received: from [10.36.116.81] (ovpn-116-81.ams2.redhat.com [10.36.116.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 37E526D147; Fri, 3 Feb 2017 17:22:11 +0000 (UTC) To: "Michael S. Tsirkin" References: <4cad5796-7024-4a48-a73a-8dd780259968@redhat.com> <20170203172140-mutt-send-email-mst@kernel.org> Cc: Ciara Loftus , mark.b.kavanagh@intel.com, Flavio Leitner , Daniele Di Proietto , "dev@openvswitch.org" , Kevin Traynor , "Daniel P. Berrange" , Yuanhan Liu , "dev@dpdk.org" , "libvir-list@redhat.com" , sean.k.mooney@intel.com From: Maxime Coquelin Message-ID: Date: Fri, 3 Feb 2017 18:22:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170203172140-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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.28]); Fri, 03 Feb 2017 17:22:15 +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 List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:22:15 -0000 On 02/03/2017 04:34 PM, 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. Is it that difficult for OVS to know with which versions of OVS it is compatible with, and propose a way to be compatible with older versions? From Nova perspective, it just has to collect supported versions strings, and select the most recent common one. > 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. Doing this, it would be libvirt role to compare key/value pairs in the json output, right? If so, it would mean teaching libvirt to compare things it knows nothing about, that are likely to evolve over time. Also, it means the port will have already been created, so I'm not clear how we would manage compatibility version. > > 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. Regards, Maxime