Re: [Xen-users] vdb and vif connection errors

Re: [Xen-users] vdb and vif connection errors

[Matt Ayres]

Tony Hernandez wrote:
> Colin,
>  
> I've had this problem too.  I've noticed that if I destroy the domU and 
> then mount the vdb through a loop back, access a file (not sure if this 
> step is necessary, but I do it), then unmount it, I'm able then to start 
> the domU.
>  
> As for your other questions, I have no idea.
>  
> 
>  
> On 4/7/06, *Colin Brown* <brownc@franklin.edu 
> <mailto:brownc@franklin.edu>> wrote:
> 
>     I hate intermittent problems ...
> 
>     Most of the time, my domUs launch just fine.  But, occasionally I get a
>     failure to connect a vdb or vif and the domU fails to completely launch
>     ("xm list" shows it is present but no console activity either through
>     "xm create -c" or through "xm console").   The log shows a stack trace
>     in DevController.py in the area of waiting for hotplug response --
>     sometimes a timeout, sometimes an error.  There is usually no indication
>     in the main log or the hotplug log as to the ultimate cause.   Usually
>     the device is the first vdb in my disk array; but often it's either
>     another of the vdb's or a vif.
> 
>     I sometimes find it's something I did wrong like mistyping a vdb file
>     name, in which case I have no cause for complaint.
> 

This seems to be an old problem re-introduced in Xen 3.0.2.  I am 
experiencing it on my test server.  In my specific scenario sometimes a 
guest won't start properly due to a vbd not "connecting" properly.  It 
occurs only when there is heavy access to xend.  Simply waiting until 
there are no other xm commands running lets the domains start-up.  At 
boot though even with the 5 second delay in starting domains some will 
exhibit this error.  On my side hotplug "cleans" itself and I'm not 
stuck with a paused domain, a simple xm create starts it right up.

Just a "me too".  I'm cross-posting this to xen-devel as I know the 
developers don't actively monitor the xen-users list as closely.

Thanks,
Matt Ayres