From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH v2 for-4.6 2/2] docs: Migration feature document Date: Wed, 26 Aug 2015 20:15:41 -0600 Message-ID: <55DE72CD.4040600@suse.com> References: <1440499228-961-1-git-send-email-andrew.cooper3@citrix.com> <1440499228-961-3-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1440499228-961-3-git-send-email-andrew.cooper3@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Xen-devel List-Id: xen-devel@lists.xenproject.org On 08/25/2015 04:40 AM, Andrew Cooper wrote: > Signed-off-by: Andrew Cooper > --- > 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/ ? > + > +# 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. > +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 :-). Also, commit id introducing the change would be helpful info. Looks like 3a9ace01 in this case. > + > +# 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 Regards, Jim > + > +# Known issues > + > +* x86 HVM guest physmap operations (not reflected in logdirty bitmap) > +* x86 HVM with PoD pages (attempts to map cause PoD allocations) > +* x86 HVM with nested-virt (no relevant information included in the > + stream) > +* x86 PV ballooning (P2M marked dirty, target frame not marked) > +* x86 PV P2M structure changes (not noticed, stale mappings used) > + > +# History > + > +------------------------------------------------------------------------ > +Date Revision Version Notes > +---------- -------- -------- ------------------------------------------- > +2015-10-24 1 Xen 4.6 Document written > +---------- -------- -------- -------------------------------------------