On Wed, 27 Jan 2010, Arnd Bergmann wrote:
Date: Wed, 27 Jan 2010 04:10:28 +0100
From: Arnd Bergmann <arnd@xxxxxxxx>
To: Vivek Kashyap <kashyapv@xxxxxxxxxx>
Cc: Anthony Liguori <aliguori@xxxxxxxxxxxxxxxxxx>,
Chris Wright <chrisw@xxxxxxxxxx>,
"libvir-list@xxxxxxxxxx" <libvir-list@xxxxxxxxxx>,
Michael S. Tsirkin <mst@xxxxxxxxxx>, vivk@xxxxxxxxxx
Subject: Re: [libvirt] Re: Supporting vhost-net and macvtap in libvirt for
QEMU
On Wednesday 20 January 2010, Vivek Kashyap wrote:
As you can see, the policy is mostly independent from the qemu
implementation and even from the kernel implementation. Naming the
macvtap code in qemu '-net vepa' would completely mix up things
for people that want to use vepa with an SR-IOV card, or macvtap
in bridge mode!
Qemu can continue to name the interface '-net tap'. libvrt can invoke it
as '-net tap, fd=x', whether the fd is of type tap or macvtap.
right.
With the above, in the domain xml, we specify:
<interface type='physical'/>
<name='somename'/>
<type='macvtap|tap'/> // one of the two to be specified
<target mode='vepa|pepa|bridge'/> //specify the mode needed for the VM
</interface>
With the above, when instantiating a guest libvirt will determine the
type of interface. Example: for a 'vepa' on device eth0, libvirt will
create a macvtap interface while setting the mode to vepa.
Sounds good. So you could passs macvtap with any of the target modes or
tap with bridge mode to get the current behaviour.
Exactly. Also, the 'target mode' comes into play only if one wants to
override the default mode for the 'bridge'. For example, macvlan bridge
can allow both 'vepa' and 'veb' (ie. briding) modes. The VM can then
specify that its interface needs to be in target mode='veb' to overcome
the default of 'vepa'.
This fd is what is passed to qemu. Since macvtap/tap appear the same to
qemu we should not have to modify anything beyond libvirt.
thoughts?
There is still the question of whether the macvtap devices should be
kept persistant and created when the daemon is started or only when
instantiating a particular VM. Normal taps are not persistent unless
you mark them to be so, while macvtap is persistant by default.
We could also add the TUNSETPERSIST ioctl to macvtap to give it
autodestruct behavior, but I'd rather avoid that if possible in order
to keep the lifetime rules simple.
Yes, we ran into this. We are creating the 'macvtap' interface when the
VM is created. The problem certainly is when the VM terminates. It seems
to me that we should, like 'tap', let macvtap auto-destruct. An option
like you suggest would be ok too.
Vivek
Arnd
__
Vivek Kashyap
Linux Technology Center, IBM
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list