[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)

On Sun, 2013-03-17 at 18:44 +0100, Daniel Pocock wrote:
> On 17/03/13 18:38, Ian Campbell wrote:
> > I'm afraid I don't know about the issue you are seeing but I can
> > comment on one part:
> > 
> > On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote:
> >> while the output from dmesg suggests that the interface vif10.0
> >> was created.  It appears there is confusion between the vifX.Y
> >> and tapX.Y naming schemes.
> > 
> > An HVM guest with a network device should get *both* vifX.Y and
> > tapX.Y, they are kind of two faces of the same "device". The tapX.Y
> > is the emulated NIC (rtl8169 or e1000 or something) while the
> > vifX.Y is the PV NIC which the guest can choose to switch over too
> > (for increased perf etc) if it has a suitable driver (e.g. Linux
> > PVHVM support, PV drivers for Windows etc etc).
> > 
> > As to why tapX.Y cannot be added to a bridge, I've no idea, sorry.
> > Are you using bridge or vswitch? Can you manually enslave the tap
> > device to the bridge?
> > 
> I'm using Open vSwitch

I wonder if something might be logged by ovs about why it is refusing
this operation? I think OVS has pretty extensive logging capabilities
too so you might be able to increase the verbosity.

> It halts the domU too quickly for me to try and manually add it to the
> bridge

IIRC there are some VM metadata fields about what to do on "crash",
"restart" etc which you can set to things like "preserve", "reboot" etc.
You could try setting them to "preserve" and see if this class of error
counts as a crash/restart etc.

> Do you have a wheezy environment where you can reproduce the problem
> and verify it is not just my system?

Unfortunately not.

Ian Campbell

We all B M
For I B M!!!!
                -- H.A.R.L.I.E.

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.