Hello,
Thank you for the fast and detailed clarifications! I have some more questions, please
find them inline.
Best regards,
Bogdan P.
-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@redhat.com]
Sent: Wednesday, April 03, 2013 1:12 PM
To: Purcareata Bogdan-B43198
Cc: libvir-list(a)redhat.com
Subject: Re: [libvirt] Networking options in libvirt_lxc
On Wed, Apr 03, 2013 at 10:04:20AM +0000, Purcareata Bogdan-B43198 wrote:
> Hello,
>
> I am doing some research on [subject] and I would like to find out some information
regarding
various scenarios. I've studied the official documentation at [1] and some of the
mailing list
archives. The configurations I have in mind are somewhat inspired by what the sf LXC
package offers in
terms of networking.
>
> What I've tested so far and works:
> - Shared networking - all host interfaces are present in the container if no
<interface> tag has
been specified in the domain configuration. I'm assuming this is because the
container is started in
the same network namespace like the host. Is it possible to make only a subset of these
interfaces
visible inside the container?
Yes, if no <interface> is listed, we do not enable network namespaces.
You can force network namespaces by setting
<features>
<privnet/>
</features>
which will mean all you get is a loopback device.
If you need to make a subset of host interfaces visible, you'd need to
use <privnet/> and then the (not yet implemented) <hostdev> mode you
describe at the end.
> - Bridge to LAN - connecting a domain interface to a host bridge;
> - Direct attachment through a Macvtap device - all 3 modes (vepa, bridge and
private) work as
expected, "passthrough" requires some capabilities in the physical device
(SRIOV), which I don't have
- assuming I have a device with this capability, is this configuration supported by
(implemented in)
the libvirt_lxc driver?
You don't need SRIOV for mode='passthrough' - it works with any host nic.
SRIOV just makes it more useful if you need to run lots of guests and each
needs its own NIC, since with mode='passthough' you have a 1:1 mapping between
NICS & guests, whereas with the other macvtap modes you have a 1:N mapping.
I'm not very familiar with how this works, but I managed to achieve something: I
connected an interface with type=direct and mode=passthrough to a container domain -
starting the domain only worked if the host interface was down. I assigned the same IP
address inside the container and ping worked with the outside network. However, ping no
longer works from the host device to the outside. Also, I can't start more than one
container in this mode for the same interface - and I assume this is because of the 1:1
mapping between NICs and guests that you mentioned. I understand that SRIOV would be
useful because it would expose more VFs, so that more guests can connect in this mode to
the same device.
So I am assuming that the container interface becomes the functional "endpoint",
and the host interface will further be used just to inspect all the traffic that passes
through it. Is my understanding correct? I'm not very familiar with low-level
networking, but I am very interested in finding out the exact behavior of this scenario.
> What other scenarios I would be interested in:
> - host network interface private to the container - much like what lxc.network.phys
is offering:
"dedicated NIC from host passed through". I've read some documentation
about <hostdev> and how to
assign PCI devices to virtual machine, but I understand this is only possible with KVM -
it's assigned
from the kernel, it makes more sense, etc. However, I've also read a thread on the
mailing list
regarding <hostdev mode="capabilities">, which offers access from a
container to a device, but it's
currenly only applicable to block and character devices. Is there currently any way to
make a host
interface private to a container?
That isn't currently support, but we could easily wire that up with
<hostdev mode='capabilities'>. It just requires a simple API call
to move the host NIC to the containers' namespace
I am not familiar with the libvirt code, but I could take a wild shot at trying to do
something about this, if you find it relevant.