[libvirt-users] nested vms and nested macvtaps
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
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
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@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
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
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@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
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@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@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
participants (2)
-
jsl6uy js16uy -
Michal Privoznik