On Tue, Jan 26, 2010 at 07:15:05PM -0800, Vivek Kashyap wrote:
On Mon, 25 Jan 2010, Anthony Liguori wrote:
Describing the bridge and modes:
So, we can define the bridge function using a new type or maybe extend
the bridge.xml itself.
interface
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
@redhat.com,
Michael S. Tsirkin m...@redhat.com, Arnd Bergmann ar...@de.ibm.com
Subject: Re: [libvirt] Re: Supporting vhost-net and macvtap in libvirt for
QEMU
On 01/21/2010 03:13 PM, Vivek Kashyap wrote:
.
Proposal:
To support the above combinations we need to be able
,
Michael S. Tsirkin m...@redhat.com, v...@us.ibm.com
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
On 01/21/2010 03:13 PM, Vivek Kashyap wrote:
.
So I think we want to maintain a concept of the qemu backend (virtio,
e1000, etc), tbhe fd that connects the qemu backend to the host (tap,
socket, macvtap, etc), and the bridge. The bridge bit gets a little
complicated. We have the
On Mon, Jan 25, 2010 at 11:38:15AM -0600, Anthony Liguori wrote:
On 01/21/2010 03:13 PM, Vivek Kashyap wrote:
.
So I think we want to maintain a concept of the qemu backend (virtio,
e1000, etc), tbhe fd that connects the qemu backend to the host (tap,
socket, macvtap, etc), and the
and in the guest:
interface type='direct'
source physical='eth0'
...
/interface
I like the simplicity of just having this in the guest XML and a way
to just indicate macvlan vs macvtap somehow.
macvlan and macvtap devices have to be created per-VM. How they're
created is
libvir-list-boun...@redhat.com wrote on 01/25/2010 12:52:37 PM:
and in the guest:
interface type='direct'
source physical='eth0'
...
/interface
I like the simplicity of just having this in the guest XML and a way
to just indicate macvlan vs macvtap somehow.
I'd rather push
.
So I think we want to maintain a concept of the qemu backend (virtio,
e1000, etc), tbhe fd that connects the qemu backend to the host (tap,
socket, macvtap, etc), and the bridge. The bridge bit gets a little
complicated. We have the following bridge cases:
- sw bridge
- normal
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
On Thu, Dec 17, 2009 at 02:32:32PM -0800, Chris Wright wrote:
The reason I brought it up here is in case libvirt would be doing both.
/dev/vhost takes an fd for a tap device or raw socket. So libvirt would
need to open both, and then becomes a question of whether libvirt only
passes the
Disclaimer: I am neither an SR-IOV nor a vhost-net expert, but I've CC'd
people that are who can throw tomatoes at me for getting bits wrong :-)
I wanted to start a discussion about supporting vhost-net in libvirt.
vhost-net has not yet been merged into qemu but I expect it will be soon
so
12 matches
Mail list logo
