Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.

[Stefan Hajnoczi]

On Wed, Apr 11, 2012 at 2:38 PM, Yan Vugenfirer <address@hidden> wrote:
> On Tue, Apr 10, 2012 at 6:47 PM, Stefan Hajnoczi <address@hidden> wrote:
>>
>> On Wed, Apr 4, 2012 at 12:44 PM, Izik Eidus
>> <address@hidden> wrote:
>> > What about this patch?, everything that was asked from Dmitry was
>> > accomplished...
>> > What prevent us from progressing with merging this patch?
>>
>> Hang on, I asked what the point of the VMware paravirt device models
>> is.  I don't think that was ever answered fully.
>>
>> I know it makes migration of existing VMware guests easy, but now we
>> have the burden of maintaining these device models, whose feature set
>> and performance will never be equivalent to virtio.  The reason is
>> because we cannot extend the device spec without breaking guests (we
>> don't control the device specification and therefore cannot add new
>> features) and we now have twice as much performance optimization work
>> if we want the same level of performance as virtio devices.
>>
>> For these reasons, I think that VMware device models can only ever be
>> 2nd class device models in QEMU.  And I wonder if the effort isn't
>> better invested in good v2v migration tooling instead of adding this
>> to QEMU.
>>
>> I'm not strongly against VMware device models in QEMU, I do see the
>> benefit too, but please explain what the plan here is.
>>
>> Stefan
>
> In my opinion there is a great opportunity to create painless
> migration method from VMWare to QEMU\KVM. You just copy image and run,
> no image conversions and no issues with V2V which are painful to debug
> to regular person. After VM is already running on top of QEMU -
> changing the devices is much easier.
> Considering that VMWare "rule" the world more or less - enabling more
> people to switch easily or at least to get a taste of QEMU\KVM is a
> huge advantage.

The problem with supporting VMware devices in order to ease v2v
migration is that it actually creates a worse user experience in the
long run.

Users will be running devices that are not integrated or supported to
the level that the virtio devices are.  The danger is that we end up
with a bad user experience because users never do the full migration
from VMware to KVM.

We need to get inside the guest to perform full v2v migration (e.g.
install guest agent).  Because of this it seems we might as well
install virtio drivers and migrate the guest at that point.  Letting
the user run the guest before this has been done only results in the
poor experience I've mentioned above.

These are the reasons why I'm not sure this effort will pay off.

What are the steps in the v2v process that you have in mind?

> Regarding optimization - adding vhost support to VMXNET3 doesn't look
> like a huge effort anyway and if you look at the patch you will see
> that we are using virtio-net mechanisms in VMXNET3 device (for example
> using virtio headers for offloading).

When you say vhost support do you mean using the vhost_net.ko
userspace interface from hw/vmxnet3.c?  All I/O emulation would still
go through the QEMU process and that defeats the biggest advantage of
vhost.

Stefan