On Thu, Mar 15, 2012 at 11:47:29AM +0000, Stefan Hajnoczi wrote: > On Thu, Mar 15, 2012 at 9:02 AM, Dmitry Fleytman > <dmitry.fleyt...@ravellosystems.com> 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 :|