From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56936) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S89Gq-0006pl-NL for qemu-devel@nongnu.org; Thu, 15 Mar 2012 07:55:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S89GS-0005Ps-0X for qemu-devel@nongnu.org; Thu, 15 Mar 2012 07:55:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11829) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S89GR-0005PY-Oc for qemu-devel@nongnu.org; Thu, 15 Mar 2012 07:54:39 -0400 Date: Thu, 15 Mar 2012 11:54:31 +0000 From: "Daniel P. Berrange" Message-ID: <20120315115431.GH2388@redhat.com> References: <1331802150-12183-1-git-send-email-dmitry.fleytman@ravellosystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 0/5] VMWare PVSCSI paravirtual device implementation Reply-To: "Daniel P. Berrange" 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 Thu, Mar 15, 2012 at 11:47:29AM +0000, 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. > > I'm for supporting these devices, but we really need another step to > move migrated guests onto virtio - otherwise users will be > disappointed with KVM's support/performance. Can you explain a bit > how you want these devices to be used? FWIW, there is a v2v tool that is able to update guest images to port them from VMware to KVM, which covers changing the drivers, but also a bunch of other things http://libguestfs.org/virt-v2v/ I can still see value in natively supporting the VMWare PV devices though, since it could facilitate people who just want to try out pre-built appliance images which were designed only to use those devices. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|