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

[Michael R. Hines]

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