3:23 p.m.
Hello all, hope all is well
this maybe outside of libvirt-users....
Can you nest macvtap devices to ultimately receive a real routable ip on
the nested vm?
I have a nested vm up and running. Both vm and nested vm are centos 7 on
arch linux host. The first vm uses a macvtap in bridge mode receives dhcp
from an external dhcp server.
I start the second vm and dhclient hangs and never receives an offer.
I stood up a static interface on the nested vm. If I initiate a ping from
within the nested vm, I can see via tcpdump that the echo request is seen
on the non-nested vm and the hosting server. The reply comes back and
stops/is answered on the hosting OS interface.
rp_filter is off. No firewall rules in play blocking dhcp or icmp
Any/all help appreciated
thanks very much
6:52 a.m.
On 08.07.2016 22:23, jsl6uy js16uy wrote:
Hello all, hope all is well
this maybe outside of libvirt-users....
Can you nest macvtap devices to ultimately receive a real routable ip on
the nested vm?
I have never tested it, but why do you want to nest macvtaps? Why not
have macvtaps in the most outer one VM and pass them thru to inner layer
VMs?
Michal
10:46 a.m.
Thanks much sir
Ease I think mainly
adding a macvtap is pretty quick, performant and works. And last but
definitely not least, ignorance of other quick easy solutions.
Well, also macvtap works on older hardware where I don't have physical
functions to passthrough via sr-iov, that is what you are pointing to with
"macvtaps in the most outer one VM and pass them thru to inner layer
VMs"?
Currently I can use macvtaps with an old HP xw8600 desktop with the
integrated broadcoms
yeah ease/hardware/ignorance
On Mon, Jul 11, 2016 at 6:52 AM, Michal Privoznik <mprivozn(a)redhat.com>
wrote:
On 08.07.2016 22:23, jsl6uy js16uy wrote:
> Hello all, hope all is well
>
> this maybe outside of libvirt-users....
> Can you nest macvtap devices to ultimately receive a real routable ip on
> the nested vm?
>
I have never tested it, but why do you want to nest macvtaps? Why not
have macvtaps in the most outer one VM and pass them thru to inner layer
VMs?
Michal
11:59 a.m.
On 11.07.2016 17:46, jsl6uy js16uy wrote:
Thanks much sir
Ease I think mainly
adding a macvtap is pretty quick, performant and works. And last but
definitely not least, ignorance of other quick easy solutions.
Well, also macvtap works on older hardware where I don't have physical
functions to passthrough via sr-iov, that is what you are pointing to with
"macvtaps in the most outer one VM and pass them thru to inner layer
VMs"?
Currently I can use macvtaps with an old HP xw8600 desktop with the
integrated broadcoms
yeah ease/hardware/ignorance
I'll be using terminology as defined here:
http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen#Introduction
What I meant is to have macvtaps for your L0 guest, which are then
visible as regular interfaces in in. These interfaces could be then
passed thru to your L1 guest. There's no need for SRI-OV, no need for
bleeding edge HW, nothing. It's all done in software.
Michal
12:56 p.m.
Thanks again very much sir
Will definitely try this path and report back
On Mon, Jul 11, 2016 at 11:59 AM, Michal Privoznik <mprivozn(a)redhat.com>
wrote:
On 11.07.2016 17:46, jsl6uy js16uy wrote:
> Thanks much sir
> Ease I think mainly
> adding a macvtap is pretty quick, performant and works. And last but
> definitely not least, ignorance of other quick easy solutions.
> Well, also macvtap works on older hardware where I don't have physical
> functions to passthrough via sr-iov, that is what you are pointing to
with
> "macvtaps in the most outer one VM and pass them thru to inner layer
> VMs"?
> Currently I can use macvtaps with an old HP xw8600 desktop with the
> integrated broadcoms
>
> yeah ease/hardware/ignorance
I'll be using terminology as defined here:
http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen#Introduction
What I meant is to have macvtaps for your L0 guest, which are then
visible as regular interfaces in in. These interfaces could be then
passed thru to your L1 guest. There's no need for SRI-OV, no need for
bleeding edge HW, nothing. It's all done in software.
Michal
5:52 p.m.
That did it sir.
added extra macvtap(s) to L0, and setup interface(s) as represented/created
in L0 as passthrough macvtaps in the machine xml to L1 and dhclient
returned with outward facing ip
Thanks very much for the help/clarification!
On Mon, Jul 11, 2016 at 12:56 PM, jsl6uy js16uy <js16uy(a)gmail.com> wrote:
Thanks again very much sir
Will definitely try this path and report back
On Mon, Jul 11, 2016 at 11:59 AM, Michal Privoznik <mprivozn(a)redhat.com>
wrote:
> On 11.07.2016 17:46, jsl6uy js16uy wrote:
> > Thanks much sir
> > Ease I think mainly
> > adding a macvtap is pretty quick, performant and works. And last but
> > definitely not least, ignorance of other quick easy solutions.
> > Well, also macvtap works on older hardware where I don't have physical
> > functions to passthrough via sr-iov, that is what you are pointing to
> with
> > "macvtaps in the most outer one VM and pass them thru to inner layer
> > VMs"?
> > Currently I can use macvtaps with an old HP xw8600 desktop with the
> > integrated broadcoms
> >
> > yeah ease/hardware/ignorance
>
> I'll be using terminology as defined here:
>
> http://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen#Introduction
>
> What I meant is to have macvtaps for your L0 guest, which are then
> visible as regular interfaces in in. These interfaces could be then
> passed thru to your L1 guest. There's no need for SRI-OV, no need for
> bleeding edge HW, nothing. It's all done in software.
>
> Michal
>
3056
days inactive
3059
days old
5 comments
2 participants
participants (2)
-
jsl6uy js16uy -
Michal Privoznik