[libvirt-users] connecting host and guest vm using a dummy nic

daggs daggs at gmx.com
Wed May 2 17:28:50 UTC 2018


Greetings Laine,

> Sent: Wednesday, May 02, 2018 at 8:09 PM
> From: "Laine Stump" <laine at redhat.com>
> To: libvirt-users at redhat.com
> Cc: daggs <daggs at gmx.com>
> 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 at redhat.com>
> >> To: libvirt-users at redhat.com
> >> Cc: daggs <daggs at gmx.com>
> >> 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).
> 
I intend to run only one vm on this system, thanks for the tip.

> 
> > 
> > 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.
> 
> 
so any network test will do?

Thanks, 

Dagg.




More information about the libvirt-users mailing list