On Wed, Oct 04, 2017 at 03:03:49PM +0200, Kevin Wolf wrote:
> Am 02.10.2017 um 21:18 hat Dr. David Alan Gilbert geschrieben:
> > Adding in kwolf; it looks sane to me; Kevin?
> > If I'm reading this right, this is just after the device state save.
>
> Is this actual migration? Because the code loo
Am 02.10.2017 um 21:18 hat Dr. David Alan Gilbert geschrieben:
> Adding in kwolf; it looks sane to me; Kevin?
> If I'm reading this right, this is just after the device state save.
Is this actual migration? Because the code looks more like it's copied
and adapted from the snapshot code rather tha
On Tue, Oct 03, 2017 at 12:33:37PM +0100, Roger Pau Monné wrote:
> On Mon, Oct 02, 2017 at 04:30:58PM +, Anthony PERARD wrote:
> > When doing a live migration of a Xen guest with libxl, the images for
> > block devices are locked by the original QEMU process, and this prevent
> > the QEMU at th
On Mon, Oct 02, 2017 at 04:30:58PM +, Anthony PERARD wrote:
> When doing a live migration of a Xen guest with libxl, the images for
> block devices are locked by the original QEMU process, and this prevent
> the QEMU at the destination to take the lock and the migration fail.
>
> From QEMU poi
Adding in kwolf; it looks sane to me; Kevin?
If I'm reading this right, this is just after the device state save.
Dave
* Anthony PERARD (anthony.per...@citrix.com) wrote:
> When doing a live migration of a Xen guest with libxl, the images for
> block devices are locked by the original QEMU proce
When doing a live migration of a Xen guest with libxl, the images for
block devices are locked by the original QEMU process, and this prevent
the QEMU at the destination to take the lock and the migration fail.
From QEMU point of view, once the RAM of a domain is migrated, there is
two QMP command
