Re: [Qemu-devel] [PATCH] rdma: rename 'x-rdma' => 'rdma'

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

On 10/25/2013 11:14 AM, Paolo Bonzini wrote:
> Il 25/10/2013 16:03, Michael R. Hines ha scritto:
>> Well, I tried posting libvirt support with this naming scheme,
>> but they didn't accepted.
>>
>> Their reason (Daniel, I think) is valid: experimental implies that it
>> shouldn't be exposed in the management software until it is
>> deemed stable at some point.
>>
>> As far we can tell, it is stable, and made very clear using the new
>> 'setup' state in the migration state machine.
> Sure, x-rdma => rdma *is* stable.  I'm not sure about x-rdma-pin-all though.
>
> Paolo
>

Use of this capability (which is disabled by default) is actually 
"safer" than migration without it - you would get an early warning well 
in advance of actually starting the iterative phases that there was not 
sufficient memory available on the destination.

Safety is all relative, of course, but I have successfully performed 
thousands of back-to-back RDMA migrations automatically looped *in a 
row* using a heavy-weight memory-stress benchmark here at IBM. Migration 
success is done by capturing the actual serial console output of the 
virtual machine while the benchmark is running and redirecting each 
migration output to a file to verify that the output matches the 
expected output of a successful migration. Migrations have been tested 
with both 14GB and 2GB virtual machine sizes (to make sure I was testing 
both 32-bit and 64-bit address boundaries). The benchmark is configured 
to have 75% stores and 25% loads and is configured to use 80% of the 
allocatable free memory of the VM (i.e. no swapping allowed).

I have defined a successful migration per the output file as follows:

1. The memory benchmark is still running and active (CPU near 100% and 
memory usage is high)
2. There are no kernel panics in the console output (regex keywords 
"panic", "BUG", "oom", etc...)
3. The VM is still responding to network activity (pings)
4. The console is still responsive by printing periodic messages 
throughout the life of the VM to the console from inside the VM using 
the 'write' command in infinite loop.

- Michael

[-- Attachment #2: Type: text/html, Size: 2822 bytes --]