Anthony Liguori wrote:
Considering VEPA enabled hardware doesn't exist today and the
standards aren't even finished being defined, I don't think it's a
really strong use case ;-)
Anthony,
VEPA enabled NIC hardware is live and kicking, maybe even @ your onboard
1Gbs NIC: the intel 82576 (--
On Wednesday 27 January 2010, Anthony Liguori wrote:
Introducing something that is known to be problematic from a security
perspective without any clear idea of what the use-case for it is is a
bad idea IMHO.
vepa on existing kernels is one use-case.
Considering
Sridhar Samudrala wrote:
On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
we already have -net socket,fd and any user that passes an fd into
that already knows what he wants to do with it. Making it work with
raw sockets is just a natural extension to this
Didn't realize that -net
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user implementation to
support the same feature set. If you ask for a network setup involving
a raw socket and vhost-net and the kernel
On 01/28/2010 08:13 AM, Anthony Liguori wrote:
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user implementation to
support the same feature set. If you ask for a network setup
On Thu, Jan 28, 2010 at 08:13:53AM -0600, Anthony Liguori wrote:
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user implementation to
support the same feature set. If you ask for a
On 01/28/2010 08:52 AM, Michael S. Tsirkin wrote:
On Thu, Jan 28, 2010 at 08:13:53AM -0600, Anthony Liguori wrote:
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw socket interface
in qemu is to get vhost-net and the qemu user
On Thu, Jan 28, 2010 at 09:05:45AM -0600, Anthony Liguori wrote:
On 01/28/2010 08:52 AM, Michael S. Tsirkin wrote:
On Thu, Jan 28, 2010 at 08:13:53AM -0600, Anthony Liguori wrote:
On 01/28/2010 07:56 AM, Michael S. Tsirkin wrote:
Now, the most important use case I see for the raw
On Thursday 28 January 2010, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Sridhar Samudrala wrote:
On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work
On 01/28/2010 10:37 AM, Michael S. Tsirkin wrote:
So actually, this is an interesting argument in favor of
turning disablenetwork from per-process as it is now
to per-file.
Yup. I think we really need a file-based restriction mechanism and so
far, neither disablenetwork or network
On Thu, Jan 28, 2010 at 11:58:48AM -0600, Anthony Liguori wrote:
On 01/28/2010 10:37 AM, Michael S. Tsirkin wrote:
So actually, this is an interesting argument in favor of
turning disablenetwork from per-process as it is now
to per-file.
Yup. I think we really need a file-based
On 01/28/2010 12:04 PM, Michael S. Tsirkin wrote:
On Thu, Jan 28, 2010 at 11:58:48AM -0600, Anthony Liguori wrote:
On 01/28/2010 10:37 AM, Michael S. Tsirkin wrote:
So actually, this is an interesting argument in favor of
turning disablenetwork from per-process as it is now
to
On Thursday 28 January 2010, Anthony Liguori wrote:
normal user uses libvirt to launch custom qemu instance. libvirt passes
an fd of a raw socket to qemu and puts the qemu process in a restricted
network namespace. user has another program running listening on a unix
domain socket and
On Tue, Jan 26, 2010 at 02:50:28PM -0600, Anthony Liguori wrote:
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can work with any network card in promisc mode.
To be clear, macvlan does
On Wed, Jan 27, 2010 at 10:34:35AM +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :). macvlan also requires hardware
support, packet socket can
On 01/27/2010 03:44 AM, Michael S. Tsirkin wrote:
On Wed, Jan 27, 2010 at 10:34:35AM +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :).
On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :).
Neither does vhost ;-) If it were just that as the difference, I'd be
inclined to agree, but macvtap is much better from a security
On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :).
Neither does vhost ;-) If it were just that as the difference, I'd
On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote:
On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main issue being that
macvtap doesn't exist on all kernels :).
On Wed, Jan 27, 2010 at 11:07:45AM -0600, Anthony Liguori wrote:
On 01/27/2010 10:59 AM, Michael S. Tsirkin wrote:
On Wed, Jan 27, 2010 at 08:07:11AM -0600, Anthony Liguori wrote:
On 01/27/2010 03:24 AM, Michael S. Tsirkin wrote:
I am not sure I agree with this sentiment. The main
On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:
In this case, the full
syntax would be:
-net vepa,if=eth0
or
-net vepa,fd=N
I still hope it's extbridge, vepa is an acronym that will likely not be
known for 99% of users.
Oh sorry, I don't care about the name at all. If you
On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:
I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine to use raw backend in
scenarios where qemu can be run as a privileged process.
libvirt need not support raw backend until we
On Wed, Jan 27, 2010 at 12:02:34PM -0600, Anthony Liguori wrote:
On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:
I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine to use raw backend in
scenarios where qemu can be run as a
On Wed, Jan 27, 2010 at 11:36:31AM -0600, Anthony Liguori wrote:
On 01/27/2010 11:25 AM, Michael S. Tsirkin wrote:
In this case, the full
syntax would be:
-net vepa,if=eth0
or
-net vepa,fd=N
I still hope it's extbridge, vepa is an acronym that will likely not be
known for 99%
On 01/27/2010 12:03 PM, Michael S. Tsirkin wrote:
On Wed, Jan 27, 2010 at 12:02:34PM -0600, Anthony Liguori wrote:
On 01/27/2010 11:54 AM, Sridhar Samudrala wrote:
I too think that we should not block raw backend in qemu just because of
security reasons. It should be perfectly fine
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work with raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper open a raw socket and a private namespace and just
pass it
On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work with
raw
sockets out of the box, with no support for opening it. Then you can have
libvirt or some wrapper
On Wednesday 27 January 2010, Sridhar Samudrala wrote:
On Wed, 2010-01-27 at 22:39 +0100, Arnd Bergmann wrote:
On Wednesday 27 January 2010, Anthony Liguori wrote:
I think -net socket,fd should just be (trivially) extended to work
with raw
sockets out of the box, with no support
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables gso/checksum
offload with raw backend. You can find the linux kernel patch to support
this feature here.
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables gso/checksum
offload with raw backend. You can find the
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that enables
On Tue, 2010-01-26 at 14:47 -0600, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
It also includes support for vnet_hdr option that
On Tue, 2010-01-26 at 14:50 -0600, Anthony Liguori wrote:
On 01/26/2010 02:47 PM, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git tree.
On 01/26/2010 05:15 PM, Sridhar Samudrala wrote:
On Tue, 2010-01-26 at 14:47 -0600, Anthony Liguori wrote:
On 01/26/2010 02:40 PM, Sridhar Samudrala wrote:
This patch adds raw socket backend to qemu and is based on Or Gerlitz's
patch re-factored and ported to the latest qemu-kvm git
On Wednesday 27 January 2010, Anthony Liguori wrote:
The raw backend can be attached to a physical device
This is equivalent to bridging with tun/tap except that it has the
unexpected behaviour of unreliable host/guest networking (which is not
universally consistent across platforms
36 matches
Mail list logo
