Re: [Xen-devel] [PATCH v2 for-4.6 2/2] docs: Migration feature document

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/08/15 03:15, Jim Fehlig wrote:
> On 08/25/2015 04:40 AM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> ---
>> v2:
>>   * %Revision and #History, following template review
>>   * Grammar fixes
>> ---
>>   docs/features/migration.pandoc |  100
>> ++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 100 insertions(+)
>>   create mode 100644 docs/features/migration.pandoc
>>
>> diff --git a/docs/features/migration.pandoc
>> b/docs/features/migration.pandoc
>> new file mode 100644
>> index 0000000..0fd227f
>> --- /dev/null
>> +++ b/docs/features/migration.pandoc
>> @@ -0,0 +1,100 @@
>> +% Migration
>> +% Revision 1
>> +
>> +\clearpage
>> +
>> +# Basics
>> +--------------- -------------
>> +        Status: **Supported**
>> +
>> +  Architecture: x86
>> +
>> +     Component: Toolstack
>> +--------------- -------------
>> +
>> +# Overview
>> +
>> +Migration is a mechanism to move a virtual machine while the VM is
>> +running.  Live migration moves a running virtual machine between two
>> +physical servers, but the same mechanism can be used for non-live
>> +migrate (pause and copy) and suspend/resume from disk.
>
> s/migrate/migration/ ?

Either is valid here, although it would be better to leave the entire
sentence in the same tense.

>
>> +
>> +# User details
>> +
>> +No hardware requirements, although hypervisor logdirty support is
>> +required for live migration.
>> +
>> +From the command line, `xl migrate/save/restore` are the top level
>> +interactions.  e.g.
>> +
>> +    xl create my-vm.cfg
>> +    xl migrate my-vm localhost
>> +
>> +or
>> +
>> +    xl create my-vm.cfg
>> +    xl save my-vm /path/to/save/file
>> +    xl restore /path/to/save/file
>> +
>> +Xen 4.6 sees the instruction of Migration v2.  There is no change for
>
> Xen 4.6 sees the introduction of Migration v2.
> Or, Xen 4.6 introduces Migration v2.

Oops.  I did mean s/instruction/introduction/.

>
>> +people using `xl`, although the `libxl` API has had an extension.
>> +
>> +# Technical details
>> +
>> +Migration is formed of several layers.  `libxc` is responsible for the
>> +contents of the VM (ram, vcpus, etc) and the live migration loop, while
>> +`libxl` is responsible for items such as emulator state.
>> +
>> +The format of the migration v2 stream is specified in two documents,
>> and
>> +is architecture neutral.  Compatibility with legacy streams is
>> +maintained via the `convert-legacy-stream` script which transforms a
>> +legacy stream into a migration v2 stream.
>> +
>> +* Documents
>> +    * `docs/specs/libxc-migration-stream.pandoc`
>> +    * `docs/specs/libxl-migration-stream.pandoc`
>> +* `libxc`
>> +    * `tools/libxc/xc_sr_*.[hc]`
>> +* `libxl`
>> +    * `tools/libxl/libxl_stream_{read,write}.c`
>> +* Scripts
>> +    * `tools/python/xen/migration/*.py`
>> +    * `tools/python/scripts/convert-legacy-stream`
>> +    * `tools/python/scripts/verify-stream-v2`
>> +
>> +Users of the `libxl` API have a new parameter `stream_version` in
>> +`domain_restore_params` which is used to distinguish between legacy and
>> +v2 migration streams, and hence whether legacy conversion is required.
>
> A question better asked when you posted the patches, but is there a
> way to detect if the receiver is V2 capable? I suspect sending a V2
> stream to a receiver capable only of V1 is not advised :-).

libxl has no concept of asking the far side for information, and
therefore no concept of advertising its features.

For querying the local libxl at build time, LIBXL_HAVE_SRM_V2 and
LIBXL_HAVE_SRM_V1 from 3a9ace01

>
> Also, commit id introducing the change would be helpful info. Looks
> like 3a9ace01 in this case.

See the reply (I am about to write) on the 0/0 thread, but I hope that
putting git sha's in this document is going to be impossible.

>
>> +
>> +# Limitations
>> +
>> +Hypervisor logdirty support is incompatible with hardware passthrough,
>> +as IOMMU faults cannot be used to track writes.
>> +
>> +While not a bug in migration specifically, VMs are very sensitive to
>> +changes in cpuid information, and cpuid levelling support currently has
>> +its issues.  Extreme care should be taken when migrating VMs between
>> +non-identical CPUs until the cpuid levelling improvements are complete.
>> +
>> +# Areas for improvement
>> +
>> +* Arm support
>> +* Linear P2M support for x86 PV
>> +* Live looping parameters
>
> * cpuid levelling

The topic of cpuid levelling is covered in the paragraph above, and is
logically separate from migration.  XenServer for examples uses it work
around various guest kernel bugs.

It is just as broken in the plain boot case as the migrate case, and I
don't wish to confuse the issues.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel