From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sauro Saltini Subject: Re: Re: drbd: and hvm Date: Sat, 01 May 2010 14:19:12 +0200 Message-ID: <4BDC1C40.5010605@shc.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org I've hit another problem, which seems to be related also to a race condition, but this time with Linux PVM's. I've installed a Slack13 x86_64 PVM which works wery well, when I try to migrate (live or not) the PVM is moved on the destination host, but, after migration completes, seems hanged... no network, no console, but still responds correctly to a "xm shutdown" and closes cleanly. In this state I've tried also to pause / unpause the VM without any effect. This happens ONLY if I let block-drbd manage the promotion of drbd resource on destination host during the migration ! If I manually promote drbd resource on the destination host just before migrating the whole process go well and the PVM is still working on dest (not freezed), also the source host is correctly drbd-demoted. Seems again something like a race condition between block-drbd and VM startup...but no qemu-dm now! Any clues ? Sauro Saltini On 30/04/2010 01:44, James Harper wrote: >> James Harper 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/'? >>>> >>>> >>> 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). >>> >> I've managed to make the creation of domU work by simply putting a >> > sleep(5); > >> statement in the middle of your conditional block ! >> > I did exactly the same thing. It might still race on a really heavily > loaded system, but I haven't had a problem with it in a few weeks of > testing. > > James > >