Debian Bug report logs - #702428
HVM fails to start with VIF / qemu-dm error

version graph

Package: xcp-xapi; Maintainer for xcp-xapi is Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>; Source for xcp-xapi is src:xen-api.

Reported by: Daniel Pocock <daniel@pocock.com.au>

Date: Wed, 6 Mar 2013 12:06:01 UTC

Severity: important

Found in version xen-api/1.3.2-14

Fixed in version 1.3.2-15+rm

Done: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Wed, 06 Mar 2013 12:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
New Bug report received and forwarded. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Wed, 06 Mar 2013 12:06:03 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: submit@bugs.debian.org
Subject: HVM fails to start with VIF / qemu-dm error
Date: Wed, 06 Mar 2013 13:03:46 +0100
Package: xcp-xapi
Version: 1.3.2-14
Severity: important

I imported a HVM from a legacy xm environment.

It is attached to one vif, the xenapi management vif

It fails to start:

# xe vm-start uuid=f2ba4767-7b4f-b416-3da6-3fe059ebfc37
The server failed to handle your request, due to an internal error.  The
given message may give details useful for debugging the problem.
message: device model failed to initialise: qemu-dm exitted unexpectedly

I've seen exactly the same error when I attach another Linux HVM to an
internal network (i.e. xapi0, xapi1, ...).

Removing the vif, it is possible to boot these HVMs

I notice that the xcp host only has a small number of qemu packages
installed:

# dpkg --list | grep qemu
ii  qemu-keymaps                         1.1.2+dfsg-5             all
       QEMU keyboard maps
ii  qemu-utils                           1.1.2+dfsg-5             i386
       QEMU utilities

while the legacy squeeze/xm environment has packages such as
xen-qemu-dm-4.0, so maybe xcp-xapi is not bringing in all necessary
dependencies?





Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Thu, 07 Mar 2013 09:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Thu, 07 Mar 2013 09:51:03 GMT) Full text and rfc822 format available.

Message #10 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 702428@bugs.debian.org, "thomas@goirand.fr >> Thomas Goirand" <thomas@goirand.fr>
Subject: log output
Date: Thu, 07 Mar 2013 10:48:57 +0100
errors from /var/log/xcp-xapi.log:



652Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xapi]
creating device emulator
652Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
Device.Dm.start domid=10
661Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
qemu-dm: should be running in the background (stdout redirected to syslog)
661Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
qemu-dm: pid = 9169. Waiting for /local/domain/0/device-model/10/state
661Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
watch: watching xenstore paths: [ /local/domain/0/device-model/10/state
] with timeout 5.000000 seconds
667Z|error||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
watch: timeout while watching xenstore after 5.000000 seconds
667Z|error||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xenops]
qemu-dm: unexpected exit with code: 1
667Z|debug||1227 UNIX /var/lib/xcp/xapi|VM.start
R:0b98978366e4|backtrace] Raised at device.ml:1606.12-57 ->
vmops.ml:627.2-32 -> vmops.ml:1123.8-104
667Z|error||1227 UNIX /var/lib/xcp/xapi|VM.start R:0b98978366e4|xapi]
Vmops.start_paused caught: INTERNAL_ERROR: [
Device.Ioemu_failed("qemu-dm exitted unexpectedly") ]



and more from /var/log/daemon.log:



xcp-fe: qemu-dm-10[9169]: domid: 10
xcp-fe: qemu-dm-10[9169]: -c config qemu network with xen bridge for
xcp-fe: qemu-dm-10[9169]: tap10.0 xapi1
xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation
not supported
xcp-fe: qemu-dm-10[9169]: /etc/xen/scripts/qemu-ifup: could not launch
network script
xcp-fe: qemu-dm-10[9169]: Could not initialize device 'tap'


The message about

   "can't add tap10.0 to bridge xapi1: Operation not supported"

seems to be the point where it fails.

xapi1 does exist and two PV domUs are connected to it already:

# brctl show xapi1
bridge name    bridge id        STP enabled    interfaces
xapi1        0000.de699bd4dc4d    no        vif1.2
                            vif3.1

It is only the HVM domU that has this error.

Why is it talking about tap10.0 and not vif10.0 in the qemu-dm log
message?  Do HVM vifs use the tapX naming convention?  Or is this the
cause of the problem?

dmesg output shows that a vif10.0 did exist briefly








Severity set to 'serious' from 'important' Request was from Daniel Pocock <daniel@pocock.com.au> to control@bugs.debian.org. (Fri, 15 Mar 2013 21:21:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Fri, 15 Mar 2013 21:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Fri, 15 Mar 2013 21:24:03 GMT) Full text and rfc822 format available.

Message #17 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: 702428@bugs.debian.org
Subject: raising to serious
Date: Fri, 15 Mar 2013 22:21:32 +0100


My impression of this bug is that HVM networking is not possible with
XCP, or at least it is not possible without some undocumented
configuration setting or missing dependency package

If there is a workaround from upstream, I would propose lowering the
severity to important again.  I am happy to test any proposed work
around and provide quick feedback.

The log output in my previous post suggests that the script has the
wrong interface name (should be `vif10.0' instead of `tap10.0' - that
suggests that it is completely unable to work the way it is, but also
may be easy to fix.

However, if it is completely broken, and if a new upstream release or
patch is available, I think there is significant value in having that
backported to wheezy.

Regards,

Daniel



Severity set to 'important' from 'serious' Request was from Thomas Goirand <thomas@goirand.fr> to control@bugs.debian.org. (Sat, 16 Mar 2013 10:51:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sat, 16 Mar 2013 11:03:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <thomas@goirand.fr>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sat, 16 Mar 2013 11:03:13 GMT) Full text and rfc822 format available.

Message #24 received at 702428@bugs.debian.org (full text, mbox):

From: Thomas Goirand <thomas@goirand.fr>
To: Daniel Pocock <daniel@pocock.com.au>, 702428@bugs.debian.org
Subject: Re: [Pkg-xen-devel] Bug#702428: raising to serious
Date: Sat, 16 Mar 2013 18:58:44 +0800
Hi Daniel,

On 03/16/2013 05:21 AM, Daniel Pocock wrote:
> My impression of this bug is that HVM networking is not possible with
> XCP, or at least it is not possible without some undocumented
> configuration setting or missing dependency package

Did you have a look at the XenServer documentation on the citrix
website? It applies to XCP as well, it is easy to find, and also quite huge.

> If there is a workaround from upstream, I would propose lowering the
> severity to important again.

Please do not set the severity to "serious" for this bug again. The
severity "serious" is for Debian policy violation. Here's the full
definition of serious bugs, as per reportbug:

"is a severe violation of Debian policy (that is, the problem is a
violation of a 'must' or 'required' directive); may or may not affect
the usability of the package. Note that non-severe policy violations may
be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also
designate other bugs as 'serious' and thus release-critical; however,
end users should not do so.). For the canonical list of issues worthing
a serious severity you can refer to this webpage:
http://release.debian.org/wheezy/rc_policy.txt."

This isn't what this bug is about. It matches more "important:

"a bug which has a major effect on the usability of a package, without
rendering it completely unusable to everyone."

XCP is usable without HVM, I did test that...

Also, ultimately, it is up to the maintainer to decide the severity of a
bug, so if I changed it once, please respect my choice. There is no need
to play BTS ping-pong. :)

> I am happy to test any proposed work around and provide quick feedback.

I would suggest that you ask your questions in the xen-api mailing list
upstream: xen-api@lists.xensource.com

> The log output in my previous post suggests that the script has the
> wrong interface name (should be `vif10.0' instead of `tap10.0' - that
> suggests that it is completely unable to work the way it is, but also
> may be easy to fix.
>
> However, if it is completely broken, and if a new upstream release or
> patch is available, I think there is significant value in having that
> backported to wheezy.

As much as I know, there's no upstream new version coming anytime soon.
They are currently working so that they can have a unique code base for
the CentOS and the Debian packages, until that is done, I don't think it
is reasonable to expect a newer version. You can also ask for that in
the upstream mailing list.

Cheers,

Thomas



Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sun, 17 Mar 2013 14:06:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sun, 17 Mar 2013 14:06:07 GMT) Full text and rfc822 format available.

Message #29 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: xen-api@lists.xensource.com
Cc: 702428@bugs.debian.org
Subject: HVM networking tap/vif bug (Debian bug 702428)
Date: Sun, 17 Mar 2013 15:02:22 +0100

Hi,

I've been testing the Debian packages ahead of the Debian 7 release
(which is very imminent)

I believe this is a serious bug[1] in the package, as it appears that
HVM networking is broken, or at the very least, requires some
undocumented configuration step

Specifically:

- I can start the HVM domU without any vif

- if I attach a vif, the domU will not start

Looking at /var/log/daemon.log, I notice:

xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation
not supported

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.

Can anybody comment on this?  Is this hardcoded into some config that I
should inspect?  Is it hard coded in the qemu-dm scripts?  It would be
very desirable to fix this before the wheezy release so that people
don't have a bad impression of XCP with HVM.

Regards,

Daniel


1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702428




Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sun, 17 Mar 2013 17:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sun, 17 Mar 2013 17:42:04 GMT) Full text and rfc822 format available.

Message #34 received at 702428@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Daniel Pocock <daniel@pocock.com.au>, 702428@bugs.debian.org
Cc: xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Sun, 17 Mar 2013 17:38:42 +0000
[Message part 1 (text/plain, inline)]
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?

Ian.

-- 
Ian Campbell


Put your brain in gear before starting your mouth in motion.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sun, 17 Mar 2013 17:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sun, 17 Mar 2013 17:45:04 GMT) Full text and rfc822 format available.

Message #39 received at 702428@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Daniel Pocock <daniel@pocock.com.au>, 702428@bugs.debian.org
Cc: xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Sun, 17 Mar 2013 17:41:39 +0000
[Message part 1 (text/plain, inline)]
On Sun, 2013-03-17 at 15:02 +0100, Daniel Pocock wrote:
> xcp-fe: qemu-dm-10[9169]: can't add tap10.0 to bridge xapi1: Operation
> not supported

A google search for "linux add tap to bridge operation not supported"
shows lots of people having this sort issue (often in the absence of
Xen) although none of the links I followed contained a solution :-(.

Ian.
-- 
Ian Campbell


Expect a letter from a friend who will ask a favor of you.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sun, 17 Mar 2013 17:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sun, 17 Mar 2013 17:48:04 GMT) Full text and rfc822 format available.

Message #44 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 702428@bugs.debian.org, xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Sun, 17 Mar 2013 18:44:19 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



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

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

Do you have a wheezy environment where you can reproduce the problem
and verify it is not just my system?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRRgDzAAoJEOm1uwJp1aqDmkIP/1oQAT0/OGyusk7dNdePlgbc
yUZkMCPaZ4+1oBpatcNIyQKqt89RWf4BNj20KepnRUmiqImBMDY8DPvVOsVHDvy5
leaWVJngAYl9RcEwn/+vyW05xYLUDNu+c00RKMIzWtJgcKOunUVuViSaXxDbAl/U
7gp4bWEepKgjmHxGOYnX5B/dmMDwNAPvbg5xMNpcnPxN9gy2ceYNAIBGTHHFZlOY
Ov1wJku2N1EPQEfmYPsgthF2m+ll86PFkHqyDTmBo8+oat52s7vNEoXGlTbTTzL4
oPp24z2ccYkUCz9NgrN2rcWeXDJrWvjAbz+q6FWfckz1yB+DxlFjY6S6jgELZ4UA
OPuVnGFXu55hM0RKWGTjCrcy+pvkoTG4O/k4TohV4T81hKAGDmTscjym+3f6Ix5W
XM8zlMNtOq3KpEa9ZITSAg9CF8hWf+tVL/2j2Vv/U8pVka6e5EZiQmcuvlPyIfSl
Y1MLz9oJ89O2LSBxu0Q4Rf92MXs58tfrR5SpTQBRSIeNd8S2Ez9uGJaHP/dDP3I2
9l909Kx+HphYfc5ULe8B8aYM7s039E4NhbNKZL0ztguMq8UkmfAGRxRW4J0RWdXT
puokiE7j/EgAoAeeAE5Q83d4JIc72TB/i5gHHS5UOfKtGZUaG5h9qqUShIqGeVxz
TaevGhz2/c/jJHD5aCgz
=ucax
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Sun, 17 Mar 2013 17:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Sun, 17 Mar 2013 17:51:03 GMT) Full text and rfc822 format available.

Message #49 received at 702428@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: 702428@bugs.debian.org, xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Sun, 17 Mar 2013 17:49:36 +0000
[Message part 1 (text/plain, inline)]
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


I B M
U B M
We all B M
For I B M!!!!
		-- H.A.R.L.I.E.
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Wed, 20 Mar 2013 22:39:16 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Wed, 20 Mar 2013 22:39:16 GMT) Full text and rfc822 format available.

Message #54 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 702428@bugs.debian.org, xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Wed, 20 Mar 2013 23:32:36 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 17/03/13 18:49, Ian Campbell wrote:
> 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.
> 

Ok, I played with it some more, there is definite progress but I still
believe something is wrong in one of the scripts:

I notice this in syslog:

 domid: 19
 -c config qemu network with xen bridge for
 tap19.0 xapi1
 can't add tap19.0 to bridge xapi1: Operation not supported
 /etc/xen/scripts/qemu-ifup: could not launch network script
 Could not initialize device 'tap'


After seeing that, I decided to look inside the script mentioned
there, /etc/xen/scripts/qemu-ifup

I found the brctl command in the script

    brctl addif $2 $1


Commented out that line so the script now returns 0 (success)

Booted the VM - it boots successfully, but without network
connectivity.  It has a VIF, but no ping

Looking at `brctl show xapi1' and I see vif20.0 is in there, but
tap20.0 is not

Manually run the command

    ovs-vsctl add-port xapi1 tap20.0

Now it is possible to ping the running HVM domU

Should the script be using the ovs-vsctl command instead of brctl?  Or
have I misconfigured something and the wrong script is being run?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJRSjkEAAoJEOm1uwJp1aqDw8EP/3Er1BTtGmfZn16kndFzklUl
gU901PTVtNOaLODI9c+ecE4Z+vBMWebPhwwXeiDEjCS32xlufJAeSBG5hf31lHt2
mhPjHMzO8MjvIicC4zqN85soNIYz0T57bjWJhUoYhPvZCnwFSoi7vegteE9der+C
J1xfh3BzdyUHNMphDsuHPuZSninEpUrZT4Ez9jRKM585UpNgM75tIMoHzzm+j/Ek
qwTZKISyc+0sd/QGwCzet3/P3lUkKXhZ296SjsBcPjqq0IHkO391xD9jCX4XMLxR
2lQMfVlvW+KciZwnKsvPWQC9NsyhtnTBZ9sSof9e/WYYsxZ9PWRDZ60QPn8RIHrg
pP0WwYbfGvs1cGj5Gu7kjq0ikhRQ4HLcE/b3S8Y8knv4/LyIZj98D+RAiIbPuq48
MF8BHFZw5QjLPPe24Dhq7684YiFUpInFvHx1i7PBJdv1RwxA32pmauPNUHLOg232
qoBjoY5IjEUJI3+OwV772DF38WqsZru25ANwbNXh4PSs4PVnCt6eXc/w70UQeNEG
7OEEkQ7qyPG4iAWQvaFlvrOnwS47g1E9ARMnLhjPGKXwU88PMawmqMf0pVlaR499
199GIc28lAnTkLJHfNs6FdJlGvp8xl0BzhGK7BSPgEm0Y83PV/COwvDFpDNLXNng
MDh3YrAb/VHQxzTnNmzj
=zyPi
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Thu, 21 Mar 2013 01:54:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Campbell <ijc@hellion.org.uk>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Thu, 21 Mar 2013 01:54:08 GMT) Full text and rfc822 format available.

Message #59 received at 702428@bugs.debian.org (full text, mbox):

From: Ian Campbell <ijc@hellion.org.uk>
To: Daniel Pocock <daniel@pocock.com.au>
Cc: 702428@bugs.debian.org, xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Thu, 21 Mar 2013 01:47:45 +0000
On Wed, 2013-03-20 at 23:32 +0100, Daniel Pocock wrote:
> 
> Should the script be using the ovs-vsctl command instead of brctl?

As a general rule one should be using the ovs tools directly wherever
possible and not the brctl compat layer.

>  Or
> have I misconfigured something and the wrong script is being run? 

This is something which AFAIR differs between upstream Xen and XCP. With
upstream Xen we disable the qemu script explicitly and expect the xen
vif hotplug scripts (which handle Xen tap devices too) to do the job,
that is the scripts under /etc/xen/scripts/vif-foo (for foo in bridge,
openvswitch etc)

Ian




Information forwarded to debian-bugs-dist@lists.debian.org, Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>:
Bug#702428; Package xcp-xapi. (Thu, 21 Mar 2013 10:39:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Pocock <daniel@pocock.com.au>:
Extra info received and forwarded to list. Copy sent to Pkg Xen <pkg-xen-devel@lists.alioth.debian.org>. (Thu, 21 Mar 2013 10:39:10 GMT) Full text and rfc822 format available.

Message #64 received at 702428@bugs.debian.org (full text, mbox):

From: Daniel Pocock <daniel@pocock.com.au>
To: Ian Campbell <ijc@hellion.org.uk>
Cc: 702428@bugs.debian.org, xen-api@lists.xensource.com
Subject: Re: [Pkg-xen-devel] Bug#702428: HVM networking tap/vif bug (Debian bug 702428)
Date: Thu, 21 Mar 2013 11:36:11 +0100
On 21/03/13 02:47, Ian Campbell wrote:
> On Wed, 2013-03-20 at 23:32 +0100, Daniel Pocock wrote:
>   
>> Should the script be using the ovs-vsctl command instead of brctl?
>>     
> As a general rule one should be using the ovs tools directly wherever
> possible and not the brctl compat layer.
>
>   
>>  Or
>> have I misconfigured something and the wrong script is being run? 
>>     
> This is something which AFAIR differs between upstream Xen and XCP. With
> upstream Xen we disable the qemu script explicitly and expect the xen
> vif hotplug scripts (which handle Xen tap devices too) to do the job,
> that is the scripts under /etc/xen/scripts/vif-foo (for foo in bridge,
> openvswitch etc)
>   
As you explained earlier, my dom0 had both a tap20.0 and a vif20.0 for
the HVM domU

I noticed that the vif20.0 interface was successfully added to the
bridge during VM creation, presumably the script responsible for that
used the ovs command instead of brctl

While I could add some permanent hack to the script I modified above,
and this might be important to include in the wheezy release, I don't
want to second-guess the strategic way of sorting this out, would you
know who is maintaining this part of XCP and how we can get some
direction on this?




Reply sent to Debian FTP Masters <ftpmaster@ftp-master.debian.org>:
You have taken responsibility. (Sun, 02 Mar 2014 18:46:11 GMT) Full text and rfc822 format available.

Notification sent to Daniel Pocock <daniel@pocock.com.au>:
Bug acknowledged by developer. (Sun, 02 Mar 2014 18:46:11 GMT) Full text and rfc822 format available.

Message #69 received at 702428-done@bugs.debian.org (full text, mbox):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>
To: 674137-done@bugs.debian.org,675052-done@bugs.debian.org,675055-done@bugs.debian.org,678723-done@bugs.debian.org,680499-done@bugs.debian.org,680500-done@bugs.debian.org,680511-done@bugs.debian.org,682216-done@bugs.debian.org,687284-done@bugs.debian.org,687936-done@bugs.debian.org,692841-done@bugs.debian.org,701554-done@bugs.debian.org,702340-done@bugs.debian.org,702428-done@bugs.debian.org,710650-done@bugs.debian.org,715333-done@bugs.debian.org,718864-done@bugs.debian.org,721345-done@bugs.debian.org,725676-done@bugs.debian.org,731718-done@bugs.debian.org,733694-done@bugs.debian.org,
Cc: xen-api@packages.debian.org, xen-api@packages.qa.debian.org
Subject: Bug#740517: Removed package(s) from unstable
Date: Sun, 02 Mar 2014 18:42:06 +0000
Version: 1.3.2-15+rm

Dear submitter,

as the package xen-api has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/740517

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)



Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Mon, 31 Mar 2014 07:33:28 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 07:16:07 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.