This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] problem about changing state to XenbusStateClosed result

To: Max Zhen <Max.Zhen@xxxxxxx>
Subject: Re: [Xen-devel] problem about changing state to XenbusStateClosed resulting in vbd entry removed from xenstore
From: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Date: Fri, 19 May 2006 00:00:34 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 18 May 2006 16:00:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <446CA038.2080009@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <446CA038.2080009@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Fri, May 19, 2006 at 12:26:32AM +0800, Max Zhen wrote:

> Hi,
> I encountered a problem while porting Solaris as a guest OS on Xen.
> The problem I found is that when frontend vbd driver get unloaded, it
> will close the vbd interface by changing the state to XenbusStateClosed.
> This appears to cause the dom0 hotplug scripts to remove the vbd entry 
> from xenstore for the domU guest, preventing the vbd from being re-attached.
> So, my questions are:
> + This doesn't seem correct since vbd's are created and destroyed from 
> Dom0 as part of domain creation 'xm create' or explicitly by executing
> 'xm block-attach'. Therefore, it would seem that devices should be
> removed either when a domU terminates or the device is explicitly
> removed from dom0 by 'xm block-detach'.

You could argue that you ought to be able to remove the frontend driver
module, and then load that module again and have all the devices reconnect.
I've no idea whether that would have knock-on consequences though.

> + Is there any other way to flush all the I/O to the disk?
> Currently, the only way to flush the I/Os is to change the frontend
> state to XenbusStateClosed.
> Since changing the state to XenbusStateClosed is a dangerous thing to do
> (cause all the vbd interface information to be removed), I cannot just
> flush the I/O, while keep the frontend and backend connected.
> Could there be any new state or command to do that?

A block-detach should be switching the backend to XenbusStateClosing, which
the frontend will observe, allowing it to flush remaining I/O.  Only when the
frontend is done should it switch to Closed, which will then be seen by the
backend and then the backend can finish up and close itself.

Are you not seeing this?



Xen-devel mailing list