RE: [Xen-devel] Hotplug scripts not working... xen/ia64 domUstopped working

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

To see if the same workaround works for you that worked for
me: edit /etc/hotplug/xen-backend.agent.  Add a -x at the
end of the first line.  Insert a line between the first
and second line with:
exec 2>>/tmp/log

Then try again.  Though our messages are different, this
changed timing enough for my problem to go away so it might
be worth a try.

Dan 

> -----Original Message-----
> From: David F Barrera [mailto:dfbp@xxxxxxxxxx] 
> Sent: Friday, December 02, 2005 2:22 PM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: Ewan Mellor; xen-devel
> Subject: RE: [Xen-devel] Hotplug scripts not working... 
> xen/ia64 domUstopped working
> 
> I wonder if what I am seeing is the same problem described in this
> thread. I am unable to create domUs on an x86_64 box, 
> something which I
> had been able to do even this morning:
> 
> VmError: Device 2070 (vbd) could not be connected. Backend device not
> found.
> 
> [2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting 
> for devices
> vif.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:125) Waiting for 0.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:398)
> hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:398)
> hotplugStatusCallback /local/domain/0/backend/vif/1/0/hotplug-status.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:415)
> hotplugStatusCallback 1.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting 
> for devices
> usb.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:119) Waiting 
> for devices
> vbd.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:125) Waiting for 2070.
> [2005-12-02 15:11:25 xend] DEBUG (DevController:398)
> hotplugStatusCallback /local/domain/0/backend/vbd/1/2070/hotplug-
> status.[2005-12-02 15:11:25 xend] DEBUG (DevController:415)
> hotplugStatusCallback 3.
> [2005-12-02 15:11:25 xend] ERROR (SrvBase:87) Request wait_for_devices
> failed.
> Traceback (most recent call last):
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/web/SrvBase.py",
>  line 85,
> in perform
>     return op_method(op, req)
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/xend/server/SrvD
> omain.py",
> line 72, in op_wait_for_devices
>     return self.dom.waitForDevices()
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py",
> line 1276, in waitForDevices
>     self.waitForDevices_(c)
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py",
> line 923, in waitForDevices_
>     return self.getDeviceController(deviceClass).waitForDevices()
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevC
> ontroller.py", line 121, in waitForDevices
>     return map(self.waitForDevice, self.deviceIDs())
>   File "/tmp/xen-
> unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevC
> ontroller.py", line 137, in waitForDevice
>     raise VmError("Device %s (%s) could not be connected. "
> VmError: Device 2070 (vbd) could not be connected. Backend device not
> found.
> 
> 
> On Fri, 2005-12-02 at 12:40 -0800, Magenheimer, Dan (HP Labs Fort
> Collins) wrote:
> > > Anyway, I'd be inclined to try the new changesets (not yet 
> > > pushed to the public
> > > tree) and see if that improves things. 
> > 
> > Same problem and same workaround on tip (8169).  Please
> > email when your new changesets get pushed and I will
> > try them.
> > 
> > > > My /etc/xen/xmdefconfig is very short:
> > > > kernel = "/tmp/xenlinux"
> > > > memory = 256
> > > > nics=0
> > > > disk = ['phy:loop0,hda1,w']  # <-change to w!
> > > > 
> > > > and after a fresh boot, I am simply doing:
> > > > 
> > > > # lomount -t ext2 -diskimage /var/xen/hda /mnt
> > > > # xend start
> > > > # xm create
> > > > 
> > > > I can see how it could be interpreted that loop0 is
> > > > being used both by domain0 and the newly created domain,
> > > > but isn't this a common use model?
> > > 
> > > Only if you want to corrupt your filesystem!  Writing to that 
> > > file via /mnt
> > > in dom0 and via /dev/hda1 in the guest ought to corrupt your 
> > > fs nicely.
> > 
> > Not as long as the image is only used from domU, correct?
> > 
> > What is the proper use model?  As I noted previously,
> > disk = ['file:/var/xen/hda,hda1,w'] results in a Linux
> > error message ("UDF-fs: No VRS found"... and, no, I do
> > not have any CD's in /etc/fstab!).  Am I spelling
> > this xmdefconfig entry incorrectly?  Or is there
> > a better way to use a disk-in-a-file as root disk for
> > a guest domain?
> > 
> > Thanks,
> > Dan
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > 
> -- 
> Regards,
> 
> David F Barrera
> Linux Technology Center
> Systems and Technology Group, IBM
> 
> "The wisest men follow their own direction. "
>                                                         Euripides
> 
> 

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