RE: Hotplug scripts not working... xen/ia64 domUstopped working

RE: Hotplug scripts not working... xen/ia64 domUstopped working

[Ian Pratt]

 
> I'd like to see a "uninstall.sh". I did for a short while 
> consider writing one myself. I know that most people aren't 
> going to uninstall Xen - it's such a lovely product that no 
> one in their right mind would uninstall it, right? - but 
> particularly for us developers, it would be nice to have 
> something that removes ALL remains of the Xen installation.
> I had severe problems because I tried to install 64-bit Xen 
> on top of a 32-bit installation and all sorts of bits and 
> pieces got very confused.

"make uninstall" is an attempt at this, but I suspect it hasn't been
kept up to date. 

It would be good to update it, and try and add stuff to remove older
versions as well.

Ian 
 
> I think it could actually be constructed based on the install 
> directory with some scripting - I'm not that good at writing 
> shell-scripts, or I would volunteer to do it myself. [I 
> hacked something up where I just took the names of 
> directories listed under the install directory and removed 
> all contents of those directories, but that's only going to 
> work as long as the files are kept in the same place each 
> time. Yet, it's quicker to do that than to run a complete 
> re-install...]
> 
> --
> Mats
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

RE: Hotplug scripts not working... xen/ia64 domUstopped working

[Petersson, Mats]

> > I'd like to see a "uninstall.sh". I did for a short while consider 
> > writing one myself. I know that most people aren't going to 
> uninstall 
> > Xen - it's such a lovely product that no one in their right 
> mind would 
> > uninstall it, right? - but particularly for us developers, 
> it would be 
> > nice to have something that removes ALL remains of the Xen 
> > installation.
> > I had severe problems because I tried to install 64-bit Xen 
> on top of 
> > a 32-bit installation and all sorts of bits and pieces got very 
> > confused.
> 
> "make uninstall" is an attempt at this, but I suspect it 
> hasn't been kept up to date. 
> 
> It would be good to update it, and try and add stuff to 
> remove older versions as well.

Except "make uninstall" only works if your build machine and target
system are the same (or at least if you have enough of the tree of
makefiles copied to your target-system). My idea is to have something
similar to install.sh that can be copied from one machine to another,
and still do the right thing. 

--
Mats
> 
> Ian 
>  
> > I think it could actually be constructed based on the install 
> > directory with some scripting - I'm not that good at writing 
> > shell-scripts, or I would volunteer to do it myself. [I hacked 
> > something up where I just took the names of directories 
> listed under 
> > the install directory and removed all contents of those 
> directories, 
> > but that's only going to work as long as the files are kept in the 
> > same place each time. Yet, it's quicker to do that than to run a 
> > complete re-install...]
> > 
> > --
> > Mats
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

RE: Hotplug scripts not working... xen/ia64 domUstopped working

[Magenheimer, Dan (HP Labs Fort Collins)]

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@us.ibm.com] 
> 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@lists.xensource.com
> > 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
> 
> 

RE: Hotplug scripts not working... xen/ia64 domUstopped working

[David F Barrera]

Different problem. Something changed the order of my drives (hotplug?),
so now /dev/sdc7 is what before had been /dev/sdb7. 

/tmp/log:

xenstore-read: couldn't read path backend/vbd/2/2072/physical-device
stat: cannot stat `/dev/sdb8': No such file or directory
stat: cannot stat `/dev/sdb8': No such file or directory
+ PATH=/etc/xen/scripts:/bin:/sbin:/usr/sbin:/usr/bin
+ case "$XENBUS_TYPE" in
+ /etc/xen/scripts/block add
xenstore-read: couldn't read path backend/vif/2/0/ip
xenstore-read: couldn't read path backend/vif/2/0/bridge
+ PATH=/etc/xen/scripts:/bin:/sbin:/usr/sbin:/usr/bin
+ case "$XENBUS_TYPE" in
+ '[' -n '' ']'
+ case "$ACTION" in
+ case "$ACTION" in
xenstore-read: couldn't read path backend/vbd/2/2071/physical-device
+ case "$ACTION" in
stat: cannot stat `/dev/sdb7': No such file or directory
stat: cannot stat `/dev/sdb7': No such file or directory
+ case "$ACTION" in


On Fri, 2005-12-02 at 13:26 -0800, Magenheimer, Dan (HP Labs Fort
Collins) wrote:
> 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@us.ibm.com] 
> > 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@lists.xensource.com
> > > 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@lists.xensource.com
> 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