[libvirt-users] nested vms and nested macvtaps

[jsl6uy js16uy]

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 at 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 at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20160711/b6601158/attachment.htm>