qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implement


From: Yan Vugenfirer
Subject: Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.
Date: Wed, 11 Apr 2012 16:38:06 +0300

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.

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).

Best regards,
Yan Vugenfirer.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]