Re: Re: drbd: and hvm

[Sauro Saltini <saltini@shc.it>]

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<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).
>>>        
>> 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
>
>