Re: [Xen-users] Bridging works fine under KVM but not Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

(reinstating the list in the cc, I presume that dropping it was
accidental).

On Thu, 2014-01-09 at 16:46 -0600, Glenn E. Bailey III wrote:
> On Thu, Jan 9, 2014 at 2:55 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> I think I've narrowed down the issue a bit. So, it appears that when I
> >> do a the "xl create" it *does* create the tap interface and adds it to
> >> the bridge. But, shortly after starting the DomU the interface
> >> disappears.
> >
> > This is what would be expected if you had "PVHVM" drivers in your HVM
> > guest. At start of day the guest has access to both an emulated
> > (vifX.Y-emu) and a PV (vifX.Y) device, which are basically two halves of
> > the same thing. As part of the boot process *if* the guest supports and
> > wants to use the PV path then it will "unplug" the emulated devices (by
> > issuing some magic I/O writes). This is done for safety since you don't
> > want to be using the same device via two paths (the need for this is
> > more obvious for block devices since it would lead to data corruption).
> 
> Ah, that makes sense. So even if qemu has "ifname=vif3.X-emu" in it's
> command line it'll still revert back to vif3.X?

The vif3.X-emu device is provided by qemu and disappears on unplug.

The vif3.X device is provided independently by the xen-netback driver in
the kernel.

>  I went ahead and added
> "model=e1000" to the vif and xen_platform_pci=0 to witness the
> behaviour. It behaved like expected but still unable to route.

"expected" means that vif3.X-emu remained and the device you saw in
guest was now emulated rather than PV. (you can inspect which with
ethtool -i <dev>)

> > I think now is a good time for you to post your guest dmesg logs. It
> > will probably also be useful to see the output of "xenstore-ls -fp".
> 
> xenstore-ls -fp: http://pastebin.com/phJ023vZ
> dmesg from guest (back with pvhvm config): http://pastebin.com/5tQ220B2

Those show that the device is being detect and is connected (state = 4 
in xenstore) according to both the front and backends.

What is the physical NIC in the host?

It might be worth playing with disabling the various offloads
(scatter-gather, tx-/rx-checksum, tso, gso, gro etc) on the various
devices. The settings can be inspected with "ethtool -k <dev>" and set
with "ethtool -K <dev> <thing> off". Device worth trying this on are the
physical NIC (eth* in the dom0) the vif devices in dom0 and the eth* in
domU.

I'd start by turning them all off everywhere (including the bridge for
good measure) and if that works then trying various subsets to narrow it
down.

Ian.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users