[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |