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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, Jan 09, 2014 at 04:47:10PM -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? 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.
> 
> > 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
> 

Here in your guest dmesg:
Xen Platform PCI: I/O protocol version 1
Netfront and the Xen platform PCI driver have been compiled for this kernel: 
unplug emulated NICs.
Blkfront and the Xen platform PCI driver have been compiled for this kernel: 
unplug emulated disks.

It suggests xen_platform_pci=0 doesn't work. I think this issue was
fixed lately. As you're using 4.2 so it's broken.

So you can try to add xen_emul_unplug=never in *guest* kernel command
line to prevent unplugging your emulated e1000 card.

But your xenstore-ls result looks legit to me. Vif 4 is in connected
state (4). Don't know why it didn't work at first glance...

Wei.

> Note that iptables and SELinux is running on the guest. With them
> disabled I get the same results.
> 
> >> I did an strace -f against the xl create to try and find out how it's
> >> creating that tap interface, but it only shows it bringing it down and
> >> then changing the mac. There were some udev rules in place called
> >> "xen-backend.rules  xend.rules" but I removed them and still see the
> >> same results.
> >
> > xl calls the hotplug scripts manually rather than via udev these days (I
> > don't recall off hand which version you are running, so I don't know if
> > that is true for you). Also I expect you'd have to restart udev for any
> > rules change to take affect.
> 
> I rebooted the host machine after removing the udev rules, it's still
> a dev box :-)

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