From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S89oa-0001ls-3X for qemu-devel@nongnu.org; Thu, 15 Mar 2012 08:29:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S89oA-0005NM-Mc for qemu-devel@nongnu.org; Thu, 15 Mar 2012 08:29:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1025) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S89oA-0005NA-EC for qemu-devel@nongnu.org; Thu, 15 Mar 2012 08:29:30 -0400 Message-ID: <4F61E0A2.2000809@redhat.com> Date: Thu, 15 Mar 2012 14:29:22 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1331802150-12183-1-git-send-email-dmitry.fleytman@ravellosystems.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Anthony Liguori , Alex Fishman , "Michael S. Tsirkin" , yvugenfi@redhat.com, Izik Eidus , qemu-devel@nongnu.org, Dmitry Fleytman , pbonzini@redhat.com On 03/15/2012 01:47 PM, Stefan Hajnoczi wrote: > On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman > wrote: > > Below is the implementation of VMWare PVSCSI device and > > command line parameters to configure vendor name and product name > > for SCSI storage are implemented. > > Latter is needed to make PVSCSI storage devices look exactly as > > on VMWare hypervisors. > > > > With this and VMWARE3 patches V2V migration problem for VMWare > > images should be solved relatively easy. > > What is the V2V strategy? > > Supporting these devices is fine if we have a way to convert guests to > use virtio. But if the plan is to keep the guests on VMware pv > devices, then that will split the development effort on support and > optimizing I/O devices. All the performance work going into > virtio-net (vhost-net), virtio-blk, and possibly virtio-scsi isn't > easy to duplicate for VMware pv devices. Also, we cannot extend > VMware devices easily while retaining compatibility. > Note, it's possible to hook vmxnet to vhost-net: - process the vmxnet ring in qemu - translate it into a virtio ring in offguest memory (placing virtio headers in offguest memory as well) - fire off vhost-net - etc. So there are still extra context switches, but we can still get some of the benefits of vhost-net. -- error compiling committee.c: too many arguments to function