[Top][All Lists]

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

[Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()

From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 9/9] Introduce VLANClientState::cleanup()
Date: Thu, 30 Apr 2009 20:16:45 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> That would only allow one such pair per VM.
> id basically becomes another type of vlan id.  To have multiple nics,
> you do:
> -net tap,vlan=off,id=1234 -net nic,model=virtio,vlan=off,id=1234
> -net tap,vlan=off,id=4321 -net nic,model=virtio,vlan=off,id=4321
> And this goes back to the notion of having all device
> front-ends/back-ends have some sort of identifier to associate one to
> the other.
>> Why not keeping all the existing infrastructure, just locking a vlan
>> against becoming more than a point-to-point link once some conflicting
>> optimization was applied? That should be easy to implement and to
>> explain to the user.
> I think you're suggesting the same thing as me, except you are saying
> make vlan=off implicit, and use vlan=XXX instead of id=XXX.

Look like. :)

> We can still make vlan=off implicit, and default id=0, so that -net tap
> net nic,model=virtio does the right thing.  However, if a user
> explicitly says -net tap,vlan=1 -net nic,model=virtio,vlan=1, it behaves
> like it used to.

That's my point. And if he tries "-net tap -net nic,model=virtio -net
nic", qemu will fall back to bus-like vlan. And if he tries do add the
third nic during runtime, there will be a descriptive error message.
That should be most elegant while not blocking optimizations (of the
common case).


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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