libxl: support Xen migration stream V2 in save/restore
Xen 4.6 introduced a new migration stream commonly referred to as "migration V2". Xen 4.6 and newer always produce this new stream, whereas Xen 4.5 and older always produce the legacy stream. Support for migration stream V2 can be detected at build time with LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not compatible, but a V2 host can accept and convert a legacy stream. Commit e7440656 changed the libxl driver to use the lowest libxl API version possible (version 0x040200) to ensure the driver builds against older Xen releases. The old 4.2 restore API does not support specifying a stream version and assumes a legacy stream, even if the incoming stream is migration V2. Thinking it has been given a legacy stream, libxl will fail to convert an incoming stream that is already V2, which causes the entire restore operation to fail. Xen's libvirt-related OSSTest has been failing since commit e7440656 landed in libvirt.git master. One of the more recent failures can be seen here http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html This patch changes the call to libxl_domain_create_restore() to include the stream version if LIBXL_HAVE_SRM_V2 is defined. The version field of the libxlSavefileHeader struct is also updated to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream version in the header matches the actual stream version produced by Xen. Along with bumping the libxl API requirement to 0x040400, this patch fixes save/restore on a migration V2 Xen host. Oddly, migration has never used the libxlSavefileHeader. It handles passing configuration in the Begin and Prepare phases, and then calls libxl directly to transfer domain state/memory in the Perform phase. A subsequent patch will add stream version handling in the Begin and Prepare phase handshaking, which will fix the migration related OSSTest failures. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Showing
想要评论请 注册 或 登录