qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH V4 1/3] net/filter: Remove vnet_hdr from filter-mirror and fi


From: Markus Armbruster
Subject: Re: [PATCH V4 1/3] net/filter: Remove vnet_hdr from filter-mirror and filter-redirector
Date: Wed, 27 Oct 2021 09:19:07 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Jason Wang <jasowang@redhat.com> writes:

> On Wed, Oct 27, 2021 at 2:40 PM Zhang, Chen <chen.zhang@intel.com> wrote:

[...]

>> > >> I wonder if we break management layer. If yes, maybe it's better to
>> > >> keep the vnet_hdr_support here.
>> > >
>> > > Yes and no,   With this series of patches, filters have ability to 
>> > > automatically
>> > > Configure the appropriate vnet_hdr_support flag according to the current 
>> > > environment.
>> > > And can report error when can't fixing the vnet_hdr(The user cannot fix 
>> > > it from the previous way ).
>> > > So I think no need for the user to configure this option, some relevant 
>> > > background knowledge required.
>> > >
>> > > For the management layer, keep the vnet_hdr_support may be meaningless 
>> > > except for compatibility.
>> > > In this situation, Do you think we still need to keep the 
>> > > vnet_hdr_support for management layer?
>> >
>> >
>> > So it depends on whether management layer like libvirt has already
>> > supported this. If yes, we may get errors using new qemu with old libvirt?
>>
>> As far as I know, Current management layer like upstream libvirt is no COLO 
>> official support yet.
>> And some real CSPs use libvirt passthrough qmp command to Qemu for manage 
>> COLO VM.
>
> So the question still, it looks to me it requires the modification of
> the layers on top of libvirt? If the answer is yes, we'd better keep
> that compatibility.

When in doubt, maintain compatibility.

We may want to deprecate parameters that have become unnecessary.

[...]




reply via email to

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