| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] make qemu handle drbd properly
On Tue, 30 Aug 2011, James Harper wrote:
> While this patch works great, I'd like to see a more generic mechanism
> for passing different backends into qemu when they are fundamentally the
> same (just /dev entries) and the setup is handled by the block-*
> scripts. A block-iscsi would need the same futzing in qemu to make it
> happen properly.
I agree
> I think it's wrong for qemu to use 'type' - the access method should be
> stated explicitly. drbd/iscsi should be set up in block-drbd/iscsi and
> then qemu should handle them the same way it handles phy: (with the
> exception that drbd may need a delay while it comes online). So maybe
> another setting in the xenstore like qemu-type or access-method or
> something which, if present, overrides the type that qemu uses when
> deciding how to access the underlying block device. I don't really like
> the name access-method, and qemu-type sounds wrong too, but can't think
> of anything better.
>
> So the changes required would be:
>
> 1. The block-drbd script would need to write an entry access-method=phy
> into xenstore into the appropriate place. Maybe also write a flag in
> there to tell qemu that the device may take a few seconds to come online
>
> 2. qemu would need to first read access-method, and then type if
> access-type doesn't exist. It would also retry the open of the device if
> the delay flag was specified. Or maybe it wouldn't hurt to always retry.
>
> If the decision makers agree with that approach I think I could come up
> with a patch...
Upstream qemu does not use xenstore to read the disk configuration and
any mechanisms we introduce at this point should work on upstream qemu
too.
I don't think qemu needs any knowledge of the backend type: the
toolstack (block scripts and/or libxenlight) should just setup a phy
backend and pass to qemu the right device name from the start.
Regarding the retries, it is probably better to handle them in the block
scripts, qemu doesn't seem the right place to put them.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home