Re: [Xen-devel] [PATCH 0/3] xen-blkback: refactor vbd remove/disconnect.

Re: [Xen-devel] [PATCH 0/3] xen-blkback: refactor vbd remove/disconnect.

[Jan Beulich]

>>> Joe Jin 08/03/11 4:10 AM >>> 
>1. start guest with the latest kernel. 
>2. attach new block device by xm block-attach in Dom0 
>3. mount new disk in guest 
>4. execute xm block-detach to detach the block device in dom0 until timeout 
>5. try to unmount the disk in guest, umount hung. at here, any IOs to the 
>device will hang. 

A bogus sequence of operations - an operator in Dom0 shouldn't remove
a device that is still in use in a guest, except as an exceptionasl measure
(and then other bad behavior is to be expected). What's the use case?

Jan

Re: [Xen-devel] [PATCH 0/3] xen-blkback: refactor vbd remove/disconnect.

[Daniel Stodden]

On Wed, 2011-08-03 at 10:53 -0400, Jan Beulich wrote:
> >>> Joe Jin 08/03/11 4:10 AM >>> 
> >1. start guest with the latest kernel. 
> >2. attach new block device by xm block-attach in Dom0 
> >3. mount new disk in guest 
> >4. execute xm block-detach to detach the block device in dom0 until timeout 

Doesn't this fail immediately in userland right now? The disconnect
attempt (blkback switching to Closing) will be acknowledged with an
error, so you'd watch backend and frontend state simultaneously.

>From there on, there might be options. Could switch back to Connected
and call it a day, but that's currently nowhere exercised, so not sure
if it's fully stable.

But the behavior established in XCP is to bail out, but leave the
backend at Closing. That means from the backend perspective, the VBD
will unplug and get cleaned up at an unspecific later point in time. But
stay operational.

Note that the latter takes udev work, to finally clean up attached disk
images after completion.

> >5. try to unmount the disk in guest, umount hung. at here, any IOs to the 
> >device will hang. 

Yeah, not so good. That's what --force would imply.

> A bogus sequence of operations - an operator in Dom0 shouldn't remove
> a device that is still in use in a guest, except as an exceptionasl measure
> (and then other bad behavior is to be expected). What's the use case?

The administrative perspective is right, but it's a valid one. And even
if you're coordinating dom0 unplug with guest umount -- there needs a
way to handly buggy coordination.

We don't have guest usage indication in the frontend record, so backends
resort to try/error instead.

I think try/error is the way to deal with it. Transaction stuff
necessary to synch a front/back-coordinated disconnect seems over the
top, and we'd probably want compat behavior anyway.

Not sure what xm/xl can or wants to do about delayed detaches. If it
sounds undesirable, we probably want to consider patch to blkback to
abort shutdown-request and flip back to Connected. 

So a controller would try in sync, fail in sync, and rolls back. So it
won't have to deal with backend detach later. Sounds simpler. I don't
think there's really a particular reason XCP chose to behave the way it
does, except low hanging fruit.

Not convinced it doesn't need transactions either, because you could see
the tool/blkback interaction race blkback/blkfront driven by guest
umount. But it may yield a simpler UI.

Please correct me where my lack of OSS toolstack understanding
struck. :)

Daniel