similar to: nested vms and nested macvtaps

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

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

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 >

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

Hello all, and hope all is well Has anyone installed / on an nvme ssd for Cent 7? Would anyone know if that is supported? I have installed using Arch Linux, but at the time, mid last year, had to patch grub to recognize nvme. Arch is obviously running a much more recent kernel. Not afraid todo some empirical leg work. Just asking if anyone had tried already thanks all for any/all help regards

Thanks much for the the reply! Some sec updates/bug fixes have been applied thru the run of 6u5 and after, but yes, still firmly in 6u5 land. Guess will have to test. Broadwell cpus do run in the OS, but "6u5" is stated as not supporting 26XXv4 chipsets. regards On Wed, Jun 15, 2016 at 4:56 PM, John R Pierce <pierce at hogranch.com> wrote: > On 6/15/2016 2:48 PM, jsl6uy

Thanks very much for the quick response/info sir Server is joined to the domain, which, I think, the info I listed demonstrates, apologies if not sssd has nothing to do with Samba. >>I somewhat understand that sir. I listed mainly to provide info on auth methods and services on the host. In case not listing affected diagnosis, and just in case samba did something different interacting on

Hello, all. Hope all is well Is it possible to install kernel and support files from 6u7 into a base 6u5 image to achieve full broadwell support in 6u5? We are "locked", clearly not fully since willing to up jump kernels, on 6u5. Thanks for any and all help

Apologies if this has been gone over, but I believe I have checked the intertubes more than a bit..... I am using libvirt and have vms booting under an OVMF.fd to use an efi firmware. I can create vms, linux ubuntu, and they will boot up. However, everytime I reboot am I dropped into the default efi shell provide by the tianocore build. Then I must walk the FS to the booting efi app and run, in

Hello all, hope all is well/happy holidays Issues with an old thread out there, valid users containing an AD group Have tried this on systems running cent7u2 and ubuntu trusty. These systems are running sssd. I can login with AD users and chown/chgrp file with AD groups. However, I can't get AD groups to work with valid users for restricting share access. If I just set individual AD users,

Hello all, hope all is well Was wondering if I'm doing something wrong/missing something. I have pxe+tftp+uefi working between 2 vms. However after the build is done and I reboot, I still come up to pxe b/c tianocore always starts, from what I've seen, with trying PXE first. Great for initial builds :) but I would like to it stop after. In the xml I am pointing to the disk to boot first.

Thanks VERY MUCH for all the info and help! Apologies for the extreme delay. I got distracted by other threads that forced out this work to later date. Also some frustration as well. ;) I completely missed this update. Apologies and thanks Will be diving back into this shortly! On Thu, Mar 24, 2016 at 3:57 PM, Laszlo Ersek <lersek@redhat.com> wrote: > On 03/21/16 19:53, jsl6uy js16uy

I am running OpenStack inside a libvirt guest that is connected to the local network via a macvtap interface. My experience so far suggests that a macvtap interface will not pass traffic with a source MAC address other than the MAC address of the interface itself...for example, if inside the guest eth0 is attached to a bridge. Is that correct, or is there some setting that will make that work?

It was reported that the macvtap device selects a different vhost (when used with multiqueue feature) for incoming packets of a single connection. Use packet hash first. Patch tested on MQ virtio_net. Signed-off-by: Krishna Kumar <krkumar2 at in.ibm.com> --- drivers/net/macvtap.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff -ruNp org/drivers/net/macvtap.c

It was reported that the macvtap device selects a different vhost (when used with multiqueue feature) for incoming packets of a single connection. Use packet hash first. Patch tested on MQ virtio_net. Signed-off-by: Krishna Kumar <krkumar2 at in.ibm.com> --- drivers/net/macvtap.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff -ruNp org/drivers/net/macvtap.c

Hi Couple of questions around macvtap direct usage: 1) is the document here current? https://libvirt.org/formatnetwork.html#examplesDirect I have been able to get host to guest network traffic without any special configuration or switch since Fedora 28 when I first started using it. Using <forward mode=vepa> requires switch port mirroring, but just using <forward mode=bridge>

On Thu, May 14, 2020 at 1:32 PM Laine Stump <laine@redhat.com> wrote: > On 5/13/20 12:52 AM, Subhendu Ghosh wrote: > > Hi > > > > Couple of questions around macvtap direct usage: > > > > 1) is the document here current? > > https://libvirt.org/formatnetwork.html#examplesDirect > > Yes. None of that has changed in any major way in many years. >

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

On Wed, Dec 17, 2014 at 01:20:54PM -0500, Vladislav Yasevich wrote: > Now that UFO is split into v4 and v6 parts, we can bring > back v4 support. Continue to handle legacy applications > by selecting the ipv6 fagment id but do not change the > gso type. This allows 2 legacy VMs to continue to communicate. > > Based on original work from Ben Hutchings. > > Fixes:

Hi there. I have configured kvm domain (rhel6.4) with ethernet bridged over macvtap, and found no filtration applied except mac. 'virsh' just silently ignoring attributes 'filterref' and 'ip address' in different formats. No error on validate stage. Config examples: ... <interface type='direct'> <mac address='52:54:00:31:ae:1a'/>