Cannot create domU

Cannot create domU

[NAHieu]

I have a problem creating domU. Below is the error:
---
...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Xen virtual console successfully installed as tty1
Event-channel device installed.
xen_blk: Initialising virtual block device driver
xen_blk: Timeout connecting to device!
xen_net: Initialising virtual ethernet driver.
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
NET: Registered protocol family 1
NET: Registered protocol family 17
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "hda1" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
---

The xen changeset is:  Fri Sep 23 04:59:31 2005
43edce5b75d62213991842e441f8f11a29081a


Here is my config file (I use command: "xm create -c tty.xen")
--
kernel = "/boot/vmlinuz-2.6-xenU"
memory = 64
maxmem = 90
name = "ttylinux"
disk = ['file:/home/nah/rootfs.tty,hda1,w']
root = "/dev/hda1 ro"
--


Anybody could tell me what is wrong?


Many thanks.
Hieu

Re: Cannot create domU

[Michael Vrable]

On Fri, Sep 23, 2005 at 11:15:14PM +0900, NAHieu wrote:
> I have a problem creating domU. Below is the error:
> ---
> ...
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> Xen virtual console successfully installed as tty1
> Event-channel device installed.
> xen_blk: Initialising virtual block device driver
> xen_blk: Timeout connecting to device!
> xen_net: Initialising virtual ethernet driver.
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> Root-NFS: No NFS server available, giving up.
> VFS: Unable to mount root fs via NFS, trying floppy.
> VFS: Cannot open root device "hda1" or unknown-block(2,0)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Jon Mason made a post yesterday where he tracked the problem down (for
him) to the changeset "Move block device bind/unbind into hotplug
scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc).  I was running into
the same problem, and so based on his detective work tried installing
hotplug (actually hotplug and udev, but the first might be enough) in
domain-0.  Domain creation now works for me.

Check to see if you have hotplug installed in your domain-0, and if not,
whether installing it makes a difference.

--Michael Vrable

Re: Cannot create domU

[Michael Vrable]

On Fri, Sep 23, 2005 at 10:37:59AM -0700, Michael Vrable wrote:
> Jon Mason made a post yesterday where he tracked the problem down (for
> him) to the changeset "Move block device bind/unbind into hotplug
> scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc).  I was running into
> the same problem, and so based on his detective work tried installing
> hotplug (actually hotplug and udev, but the first might be enough) in
> domain-0.  Domain creation now works for me.
> 
> Check to see if you have hotplug installed in your domain-0, and if not,
> whether installing it makes a difference.

Actually, more testing shows that for me (minimal Debian sarge
installation), udev does seems to be needed as well, hotplug alone
doesn't work.

--Michael Vrable

Re: Cannot create domU

[Michael Vrable]

On Fri, Sep 23, 2005 at 10:43:11AM -0700, Michael Vrable wrote:
> On Fri, Sep 23, 2005 at 10:37:59AM -0700, Michael Vrable wrote:
> > Jon Mason made a post yesterday where he tracked the problem down (for
> > him) to the changeset "Move block device bind/unbind into hotplug
> > scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc).  I was running into
> > the same problem, and so based on his detective work tried installing
> > hotplug (actually hotplug and udev, but the first might be enough) in
> > domain-0.  Domain creation now works for me.
> > 
> > Check to see if you have hotplug installed in your domain-0, and if not,
> > whether installing it makes a difference.
> 
> Actually, more testing shows that for me (minimal Debian sarge
> installation), udev does seems to be needed as well, hotplug alone
> doesn't work.

Okay, hotplug _does_ work, if I reboot before testing.  (Apparently,
having udev installed switches /proc/sys/kernel/hotplug to point to
/sbin/udevsend, but after a reboot hotplug by itself works.)

--Michael Vrable

Re: Cannot create domU

[Chris Bainbridge]

On 23/09/05, Michael Vrable <mvrable@cs.ucsd.edu> wrote:
> Jon Mason made a post yesterday where he tracked the problem down (for
> him) to the changeset "Move block device bind/unbind into hotplug
> scripts" (e9d01c5dc7b4d6b7cda9ade0d137ddb89bb204cc).  I was running into
> the same problem, and so based on his detective work tried installing
> hotplug (actually hotplug and udev, but the first might be enough) in
> domain-0.  Domain creation now works for me.
>
> Check to see if you have hotplug installed in your domain-0, and if not,
> whether installing it makes a difference.

I have the same error, I had 'hotplug-base' installed, just added
'hotplug' (these are gentoo ebuild names, hotplug-base installs
/sbin/hotplug and hotplug is /etc/hotplug scripts). It made no
difference, virtual block device still fails out. After a reboot
/proc/sys/kernel/hotplug points to /sbin/udevsend, I don't know what
it should be for xen to work?

Re: Cannot create domU

[Keir Fraser]

On 23 Sep 2005, at 23:39, Chris Bainbridge wrote:

> I have the same error, I had 'hotplug-base' installed, just added
> 'hotplug' (these are gentoo ebuild names, hotplug-base installs
> /sbin/hotplug and hotplug is /etc/hotplug scripts). It made no
> difference, virtual block device still fails out. After a reboot
> /proc/sys/kernel/hotplug points to /sbin/udevsend, I don't know what
> it should be for xen to work?

On my box /proc/sys/kernel/hotplug points at /sbin/hotplug, which runs 
a script in /etc/hotplug.d/defaults which then runs the appropriate 
agent script (/etc/hotplug/xen-backend.agent).

  -- Keir

Re: Cannot create domU

[Chris Bainbridge]

On 24/09/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> On my box /proc/sys/kernel/hotplug points at /sbin/hotplug, which runs
> a script in /etc/hotplug.d/defaults which then runs the appropriate
> agent script (/etc/hotplug/xen-backend.agent).

Ok, udevsend is the default hotplug event handler in Gentoo..
apparently /sbin/hotplug used to be, but has been deprecated

">From udev-047, udevd is capable of handling hotplug events from
modules, as well as devices, and knows to call the appropriate hotplug
rc script related to the module. (at module load, a hotplug event is
generated by the kernel, and calls whatever is defined as the hotplug
handler)."

I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it
works! Woohoo! I can now mount the virtual device. So... there is
something wrong with either xen or udevsend that should be fixed. I
have no experience with hotplug, but if someone can point me in the
right direction I'll try to debug.

Re: Cannot create domU

[Keir Fraser]

On 24 Sep 2005, at 11:54, Chris Bainbridge wrote:

> I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it
> works! Woohoo! I can now mount the virtual device. So... there is
> something wrong with either xen or udevsend that should be fixed. I
> have no experience with hotplug, but if someone can point me in the
> right direction I'll try to debug.

As I understand it, there are two standard locations for hotplug 
scripts. One is a directory called /etc/hotplug.d/<name>, the other is 
a file called /etc/hotplug/<name>.agent.

We moved our script to the latter location, as we found that to work 
across debian, suse and redhat distros (unlike /etc/hotplug.d). You'll 
probably find that udevsend is a shell script -- take a look and see if 
it tries to do any hotplug stuff.

I guess it's possible it is looking in /etc/hotplug.d. If so it really 
ought to be updated. Alternatively, some distros have /sbin/hotplug 
search in /etc/hotplug.d, but they add a script to 
/etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That 
gives you the benefit of searching in both locations.

Anyway, I think it's gentoo's udevsend that is at fault here. Every 
other distro we know of searches /etc/hotplug/ these days.

  -- Keir

Re: Cannot create domU

[NAHieu]

My problem has been fixed: I overwrited /etc/xen/scripts with the new
scripts from tools/examples found in the tree. Now domU can be
created.

Many thanks,
Hieu

On 9/24/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
>
> On 24 Sep 2005, at 11:54, Chris Bainbridge wrote:
>
> > I just tried echo /sbin/hotplug > /proc/sys/kernel/hotplug and it
> > works! Woohoo! I can now mount the virtual device. So... there is
> > something wrong with either xen or udevsend that should be fixed. I
> > have no experience with hotplug, but if someone can point me in the
> > right direction I'll try to debug.
>
> As I understand it, there are two standard locations for hotplug
> scripts. One is a directory called /etc/hotplug.d/<name>, the other is
> a file called /etc/hotplug/<name>.agent.
>
> We moved our script to the latter location, as we found that to work
> across debian, suse and redhat distros (unlike /etc/hotplug.d). You'll
> probably find that udevsend is a shell script -- take a look and see if
> it tries to do any hotplug stuff.
>
> I guess it's possible it is looking in /etc/hotplug.d. If so it really
> ought to be updated. Alternatively, some distros have /sbin/hotplug
> search in /etc/hotplug.d, but they add a script to
> /etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That
> gives you the benefit of searching in both locations.
>
> Anyway, I think it's gentoo's udevsend that is at fault here. Every
> other distro we know of searches /etc/hotplug/ these days.
>
>   -- Keir
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

Re: Cannot create domU

[Chris Bainbridge]

On 24/09/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
>
> I guess it's possible it is looking in /etc/hotplug.d. If so it really
> ought to be updated. Alternatively, some distros have /sbin/hotplug
> search in /etc/hotplug.d, but they add a script to
> /etc/hotplug.d/defaults/ which also searches in /etc/hotplug/. That
> gives you the benefit of searching in both locations.
>
> Anyway, I think it's gentoo's udevsend that is at fault here. Every
> other distro we know of searches /etc/hotplug/ these days.

Gentoo has a udev rule that runs /sbin/udev_run_hotplugd (from
/etc/udev/rules.d/50-udev.rules):

# be backward compatible for a while with the /etc/dev.d and
/etc/hotplug.d/ systems
# run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
for udevstart
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"

The path /etc/hotplug.d is hardcoded into udev_run_hotplugd - it
doesn't search anywhere else. I don't understand why it doesn't run
the agent scripts in /etc/hotplug.

Re: Cannot create domU

[Keir Fraser]

On 24 Sep 2005, at 21:00, Chris Bainbridge wrote:

> # be backward compatible for a while with the /etc/dev.d and
> /etc/hotplug.d/ systems
> # run /etc/hotplug.d/ stuff only if we came from a hotplug event, not
> for udevstart
> ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
>
> The path /etc/hotplug.d is hardcoded into udev_run_hotplugd - it
> doesn't search anywhere else. I don't understand why it doesn't run
> the agent scripts in /etc/hotplug.

Many distros have a file /etc/hotplug.d/defaults/default.hotplug. It 
runs on every hotplug event and runs the appropriate 'agent' script in 
/etc/hotplug/.

You might want to try stealing that script from a non-gentoo box (I've 
temporarily placed a copy at 
http://www.cl.cam.ac.uk/~kaf24/default.hotplug). If it works, you 
should probably try and get it added to the appropriate gentoo package.

  -- Keir

Re: Cannot create domU

[Keir Fraser]

On 26 Sep 2005, at 13:47, Greg KH wrote:

> It does just that.  Look at /etc/hotplug.d/default/ directory and see
> the file "default.hotplug"?  That is what this file does.
>
> Soon, for Gentoo, that file will go away (well, actually the udev rule
> to run that will go away first) and then you will need to use udev 
> rules
> to handle everything for hotplug.  Other distros have already switched
> over to this method with very good results.

Greg,

At the moment, installing our script at /etc/hotplug/xen-backend.agent 
'just works' for us. Are we going to need to do anything more, or 
relocate our script, to get our script called on udev-only systems? And 
would there be any danger of our script being called twice on some 
systems (once via udev; once via hotplug)?

  -- Keir

Re: Cannot create domU

[Keir Fraser]

On 26 Sep 2005, at 15:14, Greg KH wrote:

> That's been "depreciated" for quite some time now.  I would recommend
> you switch to moving your script to /etc/hotplug.d/xen/ or
> /etc/hotplug.d/default/ (depending on how your hotplug event is being
> created.  Which reminds me, how is it?  Pointers to code anywhere?)

We originally placed the script in /etc/hotplug.d/xen, but found that 
didn't work on some distros. Can't remember which ones, nor how old 
they were. We should perhaps detect such systems and treat them 
specially in our install script, and move the script back to 
/etc/hotplug.d by default.

Our main hotplug event function is in 
drivers/xen/xenbus/xenbus_probe.c, I think (it's used by our network 
driver at least). Actually xenbus registers all our virtual devices 
with sysfs, and I guess that generates some hotplug events 
automatically?

  -- Keir

Re: Cannot create domU

[Gerd Knorr]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

   Hi,

> At the moment, installing our script at /etc/hotplug/xen-backend.agent 
> 'just works' for us.

Doesn't work on SUSE Linux 10.0 as well, as all the agents are gone here 
as well.  The huge stack of shell scripts was replaced with a few udev 
rules, so it's easier to see what's going on and it also is much faster.

I've attached my current configuration.  ifup-xen goes to /sbin, the 
rules file into /etc/udev/rules.d.  With those two files in place 
auto-adding interfaces to the bridge WorksForMe[tm].  The script is sort 
of a hack though, quickly created from the vif-bridge script, with no 
way to configure stuff at the moment.

cheers,

   Gerd

[-- Attachment #2: 32-net-xen.rules --]
[-- Type: text/plain, Size: 74 bytes --]

SUBSYSTEM=="net", KERNEL=="vif*", ACTION=="add", RUN+="/sbin/ifup-xen %k"

[-- Attachment #3: ifup-xen --]
[-- Type: text/plain, Size: 829 bytes --]

#!/bin/sh
netdev="$1"
bridge="${bridge:-xenbr0}"

PATH="/sbin:/bin:/usr/sbin:/usr/bin"

# Usage: create_bridge bridge
create_bridge () {
    local bridge=$1

    # Don't create the bridge if it already exists.
    if brctl show | grep -q ${bridge}; then
	return
    fi

    brctl addbr ${bridge}
    brctl stp ${bridge} off
    brctl setfd ${bridge} 0
    ip link set ${bridge} up
}

# Usage: add_to_bridge bridge dev
add_to_bridge () {
    local bridge=$1
    local dev=$2

    # Don't add $dev to $bridge if it's already on a bridge.
    if brctl show | grep -q ${dev} ; then
	return
    fi

    brctl addif ${bridge} ${dev}
    ip link set ${dev} arp off
    ip link set ${dev} up
}

create_bridge ${bridge}
add_to_bridge ${bridge} ${netdev}

echo "$(date): $0: ${bridge} ${netdev}"		>> /tmp/net-xen
env						>> /tmp/net-xen


[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Cannot create domU

[Greg KH]

On Mon, Sep 26, 2005 at 03:41:38PM +0100, Keir Fraser wrote:
> 
> On 26 Sep 2005, at 15:14, Greg KH wrote:
> 
> >That's been "depreciated" for quite some time now.  I would recommend
> >you switch to moving your script to /etc/hotplug.d/xen/ or
> >/etc/hotplug.d/default/ (depending on how your hotplug event is being
> >created.  Which reminds me, how is it?  Pointers to code anywhere?)
> 
> We originally placed the script in /etc/hotplug.d/xen, but found that 
> didn't work on some distros. Can't remember which ones, nor how old 
> they were. We should perhaps detect such systems and treat them 
> specially in our install script, and move the script back to 
> /etc/hotplug.d by default.

Yes, some very old distros did not have the multiplexed /sbin/hotplug
program which would run stuff in /etc/hotplug.d/, but they should be all
gone now :)

> Our main hotplug event function is in 
> drivers/xen/xenbus/xenbus_probe.c

Have an online source browser anywhere?

>, I think (it's used by our network driver at least). Actually xenbus
>registers all our virtual devices with sysfs, and I guess that
>generates some hotplug events automatically?

Yes, it will.  You should _never_ call /sbin/hotplug on your own.  The
one last holdout in the kernel is the input subsystem, and that will be
fixed very soon.

thanks,

greg k-h

Re: Cannot create domU

[Keir Fraser]

>> Our main hotplug event function is in
>> drivers/xen/xenbus/xenbus_probe.c
>
> Have an online source browser anywhere?

http://lxr.xensource.com/lxr-unstable/source/drivers/xen/xenbus/ 
xenbus_probe.c?v=linux-2.6.12-xen-xen-unstable

>> , I think (it's used by our network driver at least). Actually xenbus
>> registers all our virtual devices with sysfs, and I guess that
>> generates some hotplug events automatically?
>
> Yes, it will.  You should _never_ call /sbin/hotplug on your own.  The
> one last holdout in the kernel is the input subsystem, and that will be
> fixed very soon.

Looks like we don't call it directly. I think our 'hotplug' function  
just adds useful extra variables to the environment and leaves it to  
sysfs to do the actual upcalls.

  -- Keir

Re: Cannot create domU

[Chris Bainbridge]

On 26/09/05, Gerd Knorr <kraxel@suse.de> wrote:
>
> I've attached my current configuration.  ifup-xen goes to /sbin, the
> rules file into /etc/udev/rules.d.  With those two files in place
> auto-adding interfaces to the bridge WorksForMe[tm].

Can you post your udev rules/scripts for virtual block devices? Thanks.

Re: Cannot create domU

[Greg KH]

On Mon, Sep 26, 2005 at 04:41:16PM +0100, Keir Fraser wrote:
> 
> >>Our main hotplug event function is in
> >>drivers/xen/xenbus/xenbus_probe.c
> >
> >Have an online source browser anywhere?
> 
> http://lxr.xensource.com/lxr-unstable/source/drivers/xen/xenbus/ 
> xenbus_probe.c?v=linux-2.6.12-xen-xen-unstable

Thanks for the link.

> >>, I think (it's used by our network driver at least). Actually xenbus
> >>registers all our virtual devices with sysfs, and I guess that
> >>generates some hotplug events automatically?
> >
> >Yes, it will.  You should _never_ call /sbin/hotplug on your own.  The
> >one last holdout in the kernel is the input subsystem, and that will be
> >fixed very soon.
> 
> Looks like we don't call it directly. I think our 'hotplug' function  
> just adds useful extra variables to the environment and leaves it to  
> sysfs to do the actual upcalls.

Yes, that is exactly what happens.

thanks,

greg k-h

Re: Cannot create domU

[Chris Bainbridge]

I have enabled debug in udev and hotplug. From the udevsend man page:

 udevd  takes  care  of the kernel supplied sequence number and arranges
       the events for execution in the correct order. Missing sequences delay
       the execution of the following events until a timeout is reached.

Is it possible that the events aren't being supplied in the correct
order by xen, or there is some race condition, that would cause xen to
timeout before the event arrives?

Here is a log of /sbin/hotplug, which works:

Sep 27 15:55:32 xenmaster store_evtchn = 19
Sep 27 15:55:32 xenmaster default.hotplug[2352]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug HOME=/
SHLVL=2 INTERFACE=xen-br0 DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 15:55:32 xenmaster default.hotplug[2352]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:55:32 xenmaster net.agent[2352]: add event not handled
Sep 27 15:55:32 xenmaster default.hotplug[2376]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=xen-br0
DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 15:55:32 xenmaster default.hotplug[2376]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:55:32 xenmaster net.agent[2376]: add event not handled
Sep 27 15:57:00 xenmaster default.hotplug[2398]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug
XENBUS_PATH=backend/vbd/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/769
HOME=/ SHLVL=2 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2398]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2403]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331
_=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2403]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2422]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=online mac=aa:00:00:00:00:11
PWD=/etc/hotplug domain=ubuntu bridge=xen-br0
XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1 HOME=/
SHLVL=2 PHYSDEVDRIVER=vif DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=334
_=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2420]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug HOME=/
SHLVL=2 INTERFACE=vif1.1 DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2420]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:57:00 xenmaster default.hotplug[2422]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster xen-backend.agent[2422]: in
xen-backend.agent (ACTION=online XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster xen-backend.agent[2403]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 15:57:00 xenmaster device vif1.1 entered promiscuous mode
Sep 27 15:57:00 xenmaster xen-br0: port 1(vif1.1) entering learning state
Sep 27 15:57:00 xenmaster xen-br0: topology change detected, propagating
Sep 27 15:57:00 xenmaster xen-br0: port 1(vif1.1) entering forwarding state
Sep 27 15:57:00 xenmaster default.hotplug[2417]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
PATH=/bin:/sbin:/usr/sbin:/usr/bin ACTION=add PWD=/etc/hotplug
XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1 HOME=/
SHLVL=2 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2417]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster net.agent[2420]: add event not handled
Sep 27 15:57:00 xenmaster xen-backend.agent[2417]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster default.hotplug[2453]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332
_=/bin/env)
Sep 27 15:57:00 xenmaster xen-backend.agent[2398]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 15:57:00 xenmaster default.hotplug[2453]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 15:57:00 xenmaster xen-backend.agent[2453]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 15:57:00 xenmaster default.hotplug[2430]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 15:57:00 xenmaster default.hotplug[2430]: invoke
/etc/hotplug/net.agent ()
Sep 27 15:57:00 xenmaster net.agent[2430]: add event not handled
Sep 27 15:57:00 xenmaster default.hotplug[2500]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1 ACTION=online
PWD=/etc/hotplug UDEV_LOG=3 mac=aa:00:00:00:00:11 domain=ubuntu
bridge=xen-br0 XENBUS_PATH=backend/vif/2b4375b1-c81d-45f3-a227-cd2eaa601ff7/1
UDEVD_EVENT=1 SHLVL=1 PHYSDEVDRIVER=vif DEBUG=yes
PHYSDEVBUS=xen-backend SEQNUM=334 _=/bin/env)

And udevsend, which fails:

Sep 27 16:08:51 xenmaster store_evtchn = 19
Sep 27 16:08:51 xenmaster default.hotplug[2297]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/xen-br0 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=xen-br0
DEBUG=yes SEQNUM=330 _=/bin/env)
Sep 27 16:08:51 xenmaster default.hotplug[2297]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:08:51 xenmaster net.agent[2297]: add event not handled
Sep 27 16:09:17 xenmaster default.hotplug[2332]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/3e2182e4-998e-4191-863c-a60d0f1d6962/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=331
_=/bin/env)
Sep 27 16:09:17 xenmaster default.hotplug[2332]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster xen-backend.agent[2332]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vbd)
Sep 27 16:09:17 xenmaster default.hotplug[2337]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=add PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=332
_=/bin/env)
Sep 27 16:09:17 xenmaster default.hotplug[2337]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster default.hotplug[2344]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=add
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=333 _=/bin/env)
Sep 27 16:09:17 xenmaster xen-backend.agent[2337]: in
xen-backend.agent (ACTION=add XENBUS_TYPE=vif)
Sep 27 16:09:17 xenmaster default.hotplug[2344]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:09:17 xenmaster default.hotplug[2375]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1
script=/etc/xen/scripts/vif-bridge vif=vif1.1 ACTION=online
PWD=/etc/hotplug UDEV_LOG=3 mac=aa:00:00:00:00:11 domain=ubuntu
bridge=xen-br0 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 PHYSDEVDRIVER=vif DEBUG=yes
PHYSDEVBUS=xen-backend SEQNUM=334 _=/bin/env)
Sep 27 16:09:17 xenmaster net.agent[2344]: add event not handled
Sep 27 16:09:17 xenmaster default.hotplug[2375]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:17 xenmaster xen-backend.agent[2375]: in
xen-backend.agent (ACTION=online XENBUS_TYPE=vif)
Sep 27 16:09:27 xenmaster default.hotplug[2412]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vif
DEVPATH=/devices/xen-backend/vif-1-1 ACTION=remove PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vif/3e2182e4-998e-4191-863c-a60d0f1d6962/1
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=335
_=/bin/env)
Sep 27 16:09:27 xenmaster default.hotplug[2414]: arguments
(xen-backend) env (SUBSYSTEM=xen-backend OLDPWD=/ XENBUS_TYPE=vbd
DEVPATH=/devices/xen-backend/vbd-1-769 ACTION=remove PWD=/etc/hotplug
UDEV_LOG=3 XENBUS_PATH=backend/vbd/3e2182e4-998e-4191-863c-a60d0f1d6962/769
UDEVD_EVENT=1 SHLVL=1 DEBUG=yes PHYSDEVBUS=xen-backend SEQNUM=336
_=/bin/env)
Sep 27 16:09:27 xenmaster default.hotplug[2412]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:28 xenmaster default.hotplug[2414]: invoke
/etc/hotplug/xen-backend.agent ()
Sep 27 16:09:28 xenmaster xen-backend.agent[2412]: in
xen-backend.agent (ACTION=remove XENBUS_TYPE=vif)
Sep 27 16:09:28 xenmaster xen-backend.agent[2414]: in
xen-backend.agent (ACTION=remove XENBUS_TYPE=vbd)
Sep 27 16:09:28 xenmaster default.hotplug[2448]: arguments (net) env
(SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/vif1.1 ACTION=remove
PWD=/etc/hotplug UDEV_LOG=3 UDEVD_EVENT=1 SHLVL=1 INTERFACE=vif1.1
DEBUG=yes SEQNUM=337 _=/bin/env)
Sep 27 16:09:28 xenmaster default.hotplug[2448]: invoke
/etc/hotplug/net.agent ()
Sep 27 16:09:28 xenmaster net.agent[2448]: remove event not handled

Re: Cannot create domU

[Chris Bainbridge]

I finally got it working under Gentoo by abandoning all the hotplug
stuff and just using a few udev rules:

xen udev # cat rules.d/49-xen.rules
SUBSYSTEM=="xen-backend", KERNEL=="vif*", ACTION=="online",
RUN+="/etc/xen/scripts/launch up"
SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ACTION=="add",
RUN+="/etc/xen/scripts/vbd-add %k"
SUBSYSTEM=="xen-backend", KERNEL=="vbd*", ACTION=="remove",
RUN+="/etc/xen/scripts/vbd-remove %k"
SUBSYSTEM=="xen-backend", KERNEL=="vif*", ACTION=="remove",
RUN+="/etc/xen/scripts/vif-remove %k"

xen udev # cd /etc/xen/scripts/
xen scripts # cat launch
#!/bin/sh

# the script is specified in xend config
# and passed to us. we just call it.
export PATH="/sbin:/bin:/usr/sbin:/usr/bin:$PATH"

#echo "$(date): launch $1"
#env

#echo "Running ${script} $1"
${script} $1

xen scripts # cat vbd-add
#!/bin/sh
t=$(xenstore-read "$XENBUS_PATH"/type)
params=$(xenstore-read "$XENBUS_PATH"/params)
[ -x /etc/xen/scripts/block-"$t" ] && \
    /etc/xen/scripts/block-"$t" bind $params

xen scripts # cat vbd-remove
#!/bin/sh
t=$(xenstore-read "$XENBUS_PATH"/type)
node=$(xenstore-read "$XENBUS_PATH"/node)
[ -x /etc/xen/scripts/block-"$t" ] && \
/etc/xen/scripts/block-"$t" unbind $node
# remove device backend store entries
xenstore-rm "$XENBUS_PATH"

xen scripts # cat vif-remove
#!/bin/sh
# remove device backend store entries
xenstore-rm "$XENBUS_PATH"
/sbin/ip link set ${dev} down
/sbin/brctl delif ${bridge} ${dev}

network & block device setup via udev

[Gerd Knorr]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

Chris Bainbridge wrote:
> On 26/09/05, Gerd Knorr <kraxel@suse.de> wrote:
>> I've attached my current configuration.  ifup-xen goes to /sbin, the
>> rules file into /etc/udev/rules.d.  With those two files in place
>> auto-adding interfaces to the bridge WorksForMe[tm].
> 
> Can you post your udev rules/scripts for virtual block devices? Thanks.

Uhm, well, the above was with a older xen-unstable which hasn't the 
hotplug-ified setup for disks yet.

Attached below is my current setup, running flawlessly with a fresh 
checkout.  The rules file goes to /etc/udev/rules.d, the xen-* shell 
scripts to /sbin.  No dependency on hotplug any more, everything is 
invoked directly via udev (or udevd), so this should create much less 
trouble than the xen-hotplug.agent stuff.

cheers & enjoy

   Gerd

[-- Attachment #2: 40-xen.rules --]
[-- Type: text/plain, Size: 448 bytes --]

# xen-backend block devices
SUBSYSTEM=="xen-backend", ENV{XENBUS_TYPE}=="vbd", ACTION=="add",    RUN+="/sbin/xen-vbd %k up"
SUBSYSTEM=="xen-backend", ENV{XENBUS_TYPE}=="vbd", ACTION=="remove", RUN+="/sbin/xen-vbd %k down"

# xen-backend network devices
SUBSYSTEM=="xen-backend", ENV{XENBUS_TYPE}=="vif", ACTION=="online", RUN+="/sbin/xen-vif %k up"
SUBSYSTEM=="xen-backend", ENV{XENBUS_TYPE}=="vif", ACTION=="remove", RUN+="/sbin/xen-vif %k down"


[-- Attachment #3: xen-vbd --]
[-- Type: text/plain, Size: 558 bytes --]

#!/bin/sh
# bring up and down xen-backend block devices
# called via /etc/udev/rules.4/40-xen.rules

dev="$1"
mode="$2"

export PATH="/sbin:/bin:/usr/sbin:/usr/bin"
logger -p local0.info "$(basename $0): $dev $mode [${XENBUS_PATH}]"

type=$(xenstore-read "${XENBUS_PATH}/type")
script=/etc/xen/scripts/block-${type}
test -x "$script" || exit

case "$mode" in
	up)
		params=$(xenstore-read "${XENBUS_PATH}/params")
		$script bind $params
		;;
	down)
		node=$(xenstore-read "${XENBUS_PATH}/node")
		$script unbind $node
		xenstore-rm "$XENBUS_PATH"
		;;
esac


[-- Attachment #4: xen-vif --]
[-- Type: text/plain, Size: 357 bytes --]

#!/bin/sh
# bring up and down xen-backend network devices
# called via /etc/udev/rules.4/40-xen.rules

dev="$1"
mode="$2"

export PATH="/sbin:/bin:/usr/sbin:/usr/bin"
logger -p local0.info "$(basename $0): $dev $mode [${XENBUS_PATH}]"

case "$mode" in
	up)
		if test -x "$script"; then
			$script up
		fi
		;;
	down)
		xenstore-rm "$XENBUS_PATH"
		;;
esac


[-- Attachment #5: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel