Sent: Monday, April 30, 2018 at 8:31 PM From: "Laine Stump" <laine(a)redhat.com&gt; To: libvirt-users(a)redhat.com Cc: daggs <daggs(a)gmx.com&gt; Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic On 04/27/2018 06:39 PM, daggs wrote: > Greetings all, > > I have a host machine that runs a router within a vm. > I want to allow a connection between the host and the guest so the host can connect to the lan provided by the router vm. > I've created a dummy interface with these commands: > $ ip link add ens99-dummy type dummy > $ ip link set ens99-dummy address 52:54:00:1f:d0:ff > > this resulted with this output: > $ ifconfig ens99-dummy > ens99-dummy Link encap:Ethernet HWaddr 52:54:00:1F:D0:FF > inet6 addr: fe80::84b5:24ff:fe62:c16d/64 Scope:Link > UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:899 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:0 (0.0 B) TX bytes:321727 (314.1 KiB) > > > in my libvirt's xml file I have this entry: > <interface type='direct'> > <mac address='52:54:00:0c:cb:3e'/> > <source dev='ens99-dummy' mode='private'/> > <target dev='macvtap0'/> > <model type='e1000'/> > <alias name='net0'/> > <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> > </interface> MY first question would be "Why are you using macvtap?" This unnecessarily complicates the plumbing, leading to more potential places where it could fail.

The 2nd question is - Have you looked at the dhcp server running on the guest to verify that it is indeed listening for DHCP requests on the guest-side interface associated with the macvtap interface, and that it is receiving those requests and sending a reply?

> > after the vm is up, I see the adapter in the vm and the host has one more entry: > $ ifconfig macvtap0 > macvtap0 Link encap:Ethernet HWaddr 52:54:00:0C:CB:3E > inet6 addr: fe80::5054:ff:fe0c:cb3e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:889 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:500 > RX bytes:0 (0.0 B) TX bytes:320523 (313.0 KiB) > > but when I try to request ip via dhcp from both macvtap0 and ens99-dummy I don't get any. > any idea why? Definitely you wouldn't be able to use the macvtap0 device, so if anything you would want to be using ens99-dummy, but I'm not even certain *that* would work, as I've never tried it.

You've provided no visibility into the configuration of the guest OS in your virtual machine, but in general if you want a simple connection between the host and guest that has *no other connections*, you can do this with a bare tap device: <interface type='ethernet'> <model type='e1000'/> </interface> This will show up as a single device on the host and a single device in the guest, not connected to a bridge or a macvtap device or anything, and will not need any other "ip link blah blah" type setup on the host. Simplifying your setup in this manner may make it easier to find the source of your problem.

Sent: Tuesday, May 01, 2018 at 5:30 PM From: "Laine Stump" <laine(a)redhat.com&gt; To: libvirt-users(a)redhat.com Cc: daggs <daggs(a)gmx.com&gt; Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic On 04/30/2018 03:16 PM, daggs wrote: > Greetings Laine, > >> Sent: Monday, April 30, 2018 at 8:31 PM >> From: "Laine Stump" <laine(a)redhat.com&gt; >> To: libvirt-users(a)redhat.com >> Cc: daggs <daggs(a)gmx.com&gt; >> Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic >> >> On 04/27/2018 06:39 PM, daggs wrote: >>> Greetings all, >>> >>> I have a host machine that runs a router within a vm. >>> I want to allow a connection between the host and the guest so the host can connect to the lan provided by the router vm. >>> I've created a dummy interface with these commands: >>> $ ip link add ens99-dummy type dummy >>> $ ip link set ens99-dummy address 52:54:00:1f:d0:ff >>> >>> this resulted with this output: >>> $ ifconfig ens99-dummy >>> ens99-dummy Link encap:Ethernet HWaddr 52:54:00:1F:D0:FF >>> inet6 addr: fe80::84b5:24ff:fe62:c16d/64 Scope:Link >>> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:899 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:1000 >>> RX bytes:0 (0.0 B) TX bytes:321727 (314.1 KiB) >>> >>> >>> in my libvirt's xml file I have this entry: >>> <interface type='direct'> >>> <mac address='52:54:00:0c:cb:3e'/> >>> <source dev='ens99-dummy' mode='private'/> >>> <target dev='macvtap0'/> >>> <model type='e1000'/> >>> <alias name='net0'/> >>> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> >>> </interface> >> >> MY first question would be "Why are you using macvtap?" This >> unnecessarily complicates the plumbing, leading to more potential places >> where it could fail. > misconfiguration, question is, what should be the exact config for this. > >> >> The 2nd question is - Have you looked at the dhcp server running on the >> guest to verify that it is indeed listening for DHCP requests on the >> guest-side interface associated with the macvtap interface, and that it >> is receiving those requests and sending a reply? > will test it. as said before, I'm not sure what should be the proper config in libvirt. > >> >>> >>> after the vm is up, I see the adapter in the vm and the host has one more entry: >>> $ ifconfig macvtap0 >>> macvtap0 Link encap:Ethernet HWaddr 52:54:00:0C:CB:3E >>> inet6 addr: fe80::5054:ff:fe0c:cb3e/64 Scope:Link >>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>> TX packets:889 errors:0 dropped:0 overruns:0 carrier:0 >>> collisions:0 txqueuelen:500 >>> RX bytes:0 (0.0 B) TX bytes:320523 (313.0 KiB) >>> >>> but when I try to request ip via dhcp from both macvtap0 and ens99-dummy I don't get any. >>> any idea why? >> >> Definitely you wouldn't be able to use the macvtap0 device, so if >> anything you would want to be using ens99-dummy, but I'm not even >> certain *that* would work, as I've never tried it. > so use ens99-dummy directly? My suggestion is to scrap the idea of using macvtap and a dummy link entirely, and just use a plain tap device. I can't think of any reason why you would want to use macvtap rather than tap in this case > >> >> You've provided no visibility into the configuration of the guest OS in >> your virtual machine, but in general if you want a simple connection >> between the host and guest that has *no other connections*, you can do >> this with a bare tap device: like this: >> >> <interface type='ethernet'> >> <model type='e1000'/> >> </interface> >> >> This will show up as a single device on the host and a single device in >> the guest, not connected to a bridge or a macvtap device or anything, >> and will not need any other "ip link blah blah" type setup on the host. >> Simplifying your setup in this manner may make it easier to find the >> source of your problem. >> > > ok, here is the entire xml file: (I actually meant the network configuration within the guest OS, not the libvirt config of the virtual machine it's running on) > > <domain type='kvm'> > <name>router</name> > <uuid>ed8eabe2-ced3-4224-aa12-60fb31dd3fd4</uuid> > <memory unit='KiB'>1048576</memory> > <currentMemory unit='KiB'>1048576</currentMemory> > <vcpu placement='static'>2</vcpu> > <os> > <type arch='x86_64' machine='pc-q35-2.8'>hvm</type> > <boot dev='hd'/> > </os> > <features> > <acpi/> > <apic/> > </features> > <cpu mode='host-passthrough'/> > <clock offset='utc'> > <timer name='rtc' tickpolicy='catchup'/> > <timer name='pit' tickpolicy='delay'/> > <timer name='hpet' present='no'/> > </clock> > <on_poweroff>destroy</on_poweroff> > <on_reboot>restart</on_reboot> > <on_crash>restart</on_crash> > <pm> > <suspend-to-mem enabled='no'/> > <suspend-to-disk enabled='no'/> > </pm> > <devices> > <emulator>/usr/bin/kvm</emulator> > <disk type='file' device='disk'> > <driver name='qemu' type='raw'/> > <source file='/home/router/lede-x86-64-combined-ext4.img'/> > <target dev='vda' bus='virtio'/> > <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/> > </disk> > <controller type='usb' index='0' model='ich9-ehci1'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x7'/> > </controller> > <controller type='usb' index='0' model='ich9-uhci1'> > <master startport='0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x0' multifunction='on'/> > </controller> > <controller type='usb' index='0' model='ich9-uhci2'> > <master startport='2'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x1'/> > </controller> > <controller type='usb' index='0' model='ich9-uhci3'> > <master startport='4'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1d' function='0x2'/> > </controller> > <controller type='sata' index='0'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> > </controller> > <controller type='pci' index='0' model='pcie-root'/> > <controller type='pci' index='1' model='dmi-to-pci-bridge'> > <model name='i82801b11-bridge'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> > </controller> > <controller type='pci' index='2' model='pci-bridge'> > <model name='pci-bridge'/> > <target chassisNr='2'/> > <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> > </controller> > <controller type='pci' index='3' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='3' port='0x8'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0' multifunction='on'/> > </controller> > <controller type='pci' index='4' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='4' port='0x9'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> > </controller> > <controller type='pci' index='5' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='5' port='0xa'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> > </controller> > <controller type='pci' index='6' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='6' port='0xb'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x3'/> > </controller> > <controller type='pci' index='7' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='7' port='0xc'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x4'/> > </controller> > <controller type='pci' index='8' model='pcie-root-port'> > <model name='ioh3420'/> > <target chassis='8' port='0xd'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x5'/> > </controller> > <interface type='direct'> > <mac address='52:54:00:e7:90:bc'/> > <source dev='ens99-dummy' mode='vepa'/> > <model type='rtl8139'/> > <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> > </interface> > <serial type='pty'> > <target type='isa-serial' port='0'/> > </serial> > <console type='pty'> > <target type='serial' port='0'/> > </console> > <input type='mouse' bus='ps2'/> > <input type='keyboard' bus='ps2'/> > <hostdev mode='subsystem' type='usb' managed='yes'> > <source> > <vendor id='0x148f'/> > <product id='0x5572'/> > </source> > <address type='usb' bus='0' port='1'/> > </hostdev> > <hostdev mode='subsystem' type='pci' managed='yes'> > <source> > <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> > </source> > <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> > </hostdev> > <hostdev mode='subsystem' type='pci' managed='yes'> > <source> > <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> > </source> > <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> > </hostdev> > <hostdev mode='subsystem' type='pci' managed='yes'> > <source> > <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> > </source> > <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> > </hostdev> > <memballoon model='virtio'> > <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> > </memballoon> > </devices> > </domain> > > what I don't get is how to connect the interface above to the dummy one I've created. > That's easy. Don't - see my suggestion above about using a tap device instead of the macvtap+dummy combination (actually, I had thought the "<source dev='ens99-dummy' ..." should connect the two, but according to your experiments that doesn't result in a working setup, so...)

Sent: Wednesday, May 02, 2018 at 5:56 PM From: "Laine Stump" <laine(a)redhat.com&gt; To: libvirt-users(a)redhat.com Cc: daggs <daggs(a)gmx.com&gt; Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic On 05/01/2018 12:12 PM, daggs wrote: > > I want to see if I understood you correctly, I add: > <interface type='ethernet'> > <model type='e1000'/> > </interface> > to the vm's xml, this will result in a new nic in the vm which and in the host which I can use by the host to request dhcp from the router within the vm? > Yes. As long as the emulated device in the guest is listening for DHCP on that interface. Also, note that (as long as your libvirt is at least version 2.1.0) if you don't want to bother doing dhcp on the host and guest, you can assign just a static IP address for the host side of that interface in the libvirt XML like this: <interface type='ethernet'> <source> <ip address='192.168.254.2'/> </source> ... You can even specify routes to be added automatically to the host when that guest is started, e.g.: <interface type='ethernet'> <source> <ip address='192.168.254.2'/> <route family='ipv4' address='0.0.0.0' prefix='0' gateway='192.168.254.1' metric='1'/> </source> ... (this assumes that on the guest side, the OS has configured the emulated ethernet device to have address 192.168.254.1). This can be useful if you want the host to use one path for traffic when the guest isn't running, but switch when the guest *is* running. (In this case, if you can set the default route on the host to have a metric of 2 or higher, then the default route that goes through the guest would be preferred when present). (NB: if you read the documentation for configuring interfaces at https://libvirt.org/formatdomain.html#ipconfig you'll see references on how to configure the IP address of the *guest* in libvirt's xml. Note that this *does not work* for qemu, but only for lxc (and possibly xen, I don't recall right now). This is a limitation of the way that qemu/kvm works (the fact that all guest-side IP info is configured in the guest OS, and libvirt has no reasonable to get to it).)

Sent: Wednesday, May 02, 2018 at 8:09 PM From: "Laine Stump" <laine(a)redhat.com&gt; To: libvirt-users(a)redhat.com Cc: daggs <daggs(a)gmx.com&gt; Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic On 05/02/2018 12:05 PM, daggs wrote: > Greetings Laine, > >> Sent: Wednesday, May 02, 2018 at 5:56 PM >> From: "Laine Stump" <laine(a)redhat.com&gt; >> To: libvirt-users(a)redhat.com >> Cc: daggs <daggs(a)gmx.com&gt; >> Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic >> >> On 05/01/2018 12:12 PM, daggs wrote: >>> >>> I want to see if I understood you correctly, I add: >>> <interface type='ethernet'> >>> <model type='e1000'/> >>> </interface> >>> to the vm's xml, this will result in a new nic in the vm which and in the host which I can use by the host to request dhcp from the router within the vm? >>> >> >> >> Yes. As long as the emulated device in the guest is listening for DHCP >> on that interface. >> >> Also, note that (as long as your libvirt is at least version 2.1.0) if >> you don't want to bother doing dhcp on the host and guest, you can >> assign just a static IP address for the host side of that interface in >> the libvirt XML like this: >> >> >> <interface type='ethernet'> >> <source> >> <ip address='192.168.254.2'/> >> </source> >> ... >> >> You can even specify routes to be added automatically to the host when >> that guest is started, e.g.: >> >> >> <interface type='ethernet'> >> <source> >> <ip address='192.168.254.2'/> >> <route family='ipv4' address='0.0.0.0' prefix='0' >> gateway='192.168.254.1' metric='1'/> >> </source> >> ... >> >> (this assumes that on the guest side, the OS has configured the emulated >> ethernet device to have address 192.168.254.1). This can be useful if >> you want the host to use one path for traffic when the guest isn't >> running, but switch when the guest *is* running. (In this case, if you >> can set the default route on the host to have a metric of 2 or higher, >> then the default route that goes through the guest would be preferred >> when present). >> >> (NB: if you read the documentation for configuring interfaces at >> https://libvirt.org/formatdomain.html#ipconfig you'll see references on >> how to configure the IP address of the *guest* in libvirt's xml. Note >> that this *does not work* for qemu, but only for lxc (and possibly xen, >> I don't recall right now). This is a limitation of the way that qemu/kvm >> works (the fact that all guest-side IP info is configured in the guest >> OS, and libvirt has no reasonable to get to it).) >> >> > > thanks alot! > like you've said, I've defined the interface in the xml, booted the device and updated /etc/network/interfaces to alloc dhcp to vnet0. > that resulted in the proper ip and I can see the router inside the vm. BTW, if you'll be running other guests on your host, and may start them in different orders, you should probably add "<target dev='vmrouter'/> (or whatever name you like, 15 chars or less and *not* starting with "vnet") to the <interface> config. IF you do that, you can be assured that the name of the device on the host will always be consistently named "vmrouter" (otherwise it just gets the lowest numbered available "vnetX" device name each time it's started).

> > one thing bothers me, ethtool vnet0 says the speed is 10Mb/s, asking google suggested several solutions. > I've tried changing the model to virtio but the speed stays the same, the vm router is running kernel 4.4.92, could that be the issue? The reported speed should be inconsequential, since there is no wire and no physical switch involved. It will transfer data as fast as the code can be executed. Also, if virtio works, then *definitely* use that instead of e1000 - the performance will be much better and overhead much lower.

Sent: Thursday, May 03, 2018 at 1:13 AM From: "Laine Stump" <laine(a)redhat.com&gt; To: libvirt-users(a)redhat.com Cc: daggs <daggs(a)gmx.com&gt; Subject: Re: [libvirt-users] connecting host and guest vm using a dummy nic On 05/02/2018 01:28 PM, daggs wrote: >> Sent: Wednesday, May 02, 2018 at 8:09 PM >> From: "Laine Stump" <laine(a)redhat.com&gt; >> >> Also, if virtio works, then *definitely* use that instead of e1000 - the >> performance will be much better and overhead much lower. >> >> > so any network test will do? > Do you mean to test and see if virtio-net is acceptable for your guest OS? If the guest OS has the driver for virtio-net, then definitely you should use it. I've never heard of a case of any of the drivers that emulate real hardware performing anywhere near as well as virtio-net.