| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: drbd: and hvm
James Harper <james.harper <at> bendigoit.com.au> writes:
>
> >
> > What is it that prevents drbd: devices from not working under HVM?
> Could
> > the fix just be as simple as mapping 'drbd:name-of-resource' to
> > '/dev/drbd/by-res/<name-of-resource>'?
> >
>
> The following patch maps it correctly, but it only works if the device
> is already 'primary', which kind of defeats the purpose... qemu-dm must
> be trying to open the device before the drbd script switches the local
> node to 'primary'. Might it still be a useful addition to qemu-dm
> though? (eg it would work in a multiple-primary setup).
>
> James
>
> diff --git a/xenstore.c b/xenstore.c
> index 05a1c22..b53f474 100644
> --- a/xenstore.c
> +++ b/xenstore.c
> @@ -513,6 +513,14 @@ void xenstore_parse_domain_config(int hvm_domid)
> params = newparams;
> format = &bdrv_raw;
> }
> + /* handle drbd mapping */
> + if (!strcmp(drv, "drbd")) {
> + char *newparams = malloc(17 + strlen(params) + 1);
> + sprintf(newparams, "/dev/drbd/by-res/%s", params);
> + free(params);
> + params = newparams;
> + format = &bdrv_raw;
> + }
>
> #if 0
> /* Phantom VBDs are disabled because the use of paths
>
Hi, I've found your patch digging around, in the hope of making HVM DomU's
working with drbd: syntax and succesfully applied in my installation (Xen 4.0)
I've investigated a bit further, and found that the "xm create" of a such
configured DomU on a drbd "Secondary" node (i.e during initial startup of the
cluster) doesn't work as expected apparently only for timing issues...
In fact the block-drbd script is started and promotes the node to Primary, but
qemu-dm, which is fired a little time before in an asynchronous way, checks for
the resource state too early and finding it still not promoted stops the domU
creation; then the block-drbd is fired again (during DomU stop) and demotes the
node again to secondary.
I've managed to make the creation of domU work by simply putting a sleep(5);
statement in the middle of your conditional block !
In this way the asynchronous block-drbd launch is given the time to promote the
resource while qemu-drbd sleeps! Then the DomU creation can continue just fine.
I've also noticed that the problem happens only for initial creation (xm create)
of the domU, while a migration (even live) can succeed without the need of
adding the sleep statement, carrying out the correct state transitions of drbd
resource both on starting and destination hosts.
Any ideas to elaborate the patch making it less "hackish" than this ?
Sauro Saltini.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home