Re: [PATCH] Fix restore handling checks

[Michal Novotny <minovotn@redhat.com>]

On 06/23/2010 03:51 PM, Dan Magenheimer wrote:
>> From: Michal Novotny [mailto:minovotn@redhat.com]
>>
>> Honestly I don't know about how tmem features work since I have them
>> disabled because I'm unable to start any guest with them enabled
>> because it fails on creation.
>>      
> If you are booting Xen enabling tmem and NOT setting dom0_mem=
> there was a bug just reported and fixed (or patch posted at
> least).  If this is another problem with tmem (e.g. you ARE
> setting both tmem and dom0_mem), please tell me more.
>
> However, note that just enabling tmem in Xen doesn't do
> anything.  Tmem must also be enabled in guests.
>
>    

Well, I double-checked the configuration and I was not using dom0_mem on 
HV command-line so this is the bug I hit. It's a version about week old 
or something like that so I guess it was the issue I met.

>> Why should it give too many false-positives/false-negatives...
>>      
> The issue is that in a tmem system (with self-ballooning enabled
> which will be the default for tmem-enabled guests), all the
> guests are dynamically changing in size between their maximum
> memory and some minimum which may be smaller than the mem=
> they were launched with.
>
> And "free" memory as reported by Xen is also changing dynamically
> due to guest tmem calls.
>
> The only way to ensure a fixed amount of memory is available is:
> 1) freeze tmem
> 2) get free memory and "tmem freeable" memory and if there
>     is enough
> 3) ALLOCATE the memory NOW
> 4) check to ensure the allocation worked
> 5) unfreeze tmem
>
> The code in xends currently does this when launching new domains.
>
> Tmem freeze only stops tmem from allocating more free memory
> from Xen (by failing all tmem calls from tmem-enabled guests).
> It doesn't stop guest ballooning activity.  So even the
> "ALLOCATE the memory NOW" may fail... but that is acceptable
> when launching a new domain.
>
> Hope that helps,
> Dan
>
>    
Oh, ok. Then I guess that the patch could be dropped since there are 
objections against both IDE read-only disk violation and memory check 
parts, i.e. against both parts.

Michal

-- 
Michal Novotny<minovotn@redhat.com>, RHCE
Virtualization Team (xen userspace), Red Hat