[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] migration: update docs
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH v2] migration: update docs |
Date: |
Fri, 27 Apr 2018 13:14:53 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
On 04/27/2018 12:34 PM, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
>
> Update the migration docs:
>
> Among other changes:
> * Added a general list of advice for device authors
> * Reordered the section on conditional state (subsections etc)
> into the order we prefer.
> * Add a note about firmware
>
> Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> ---
> docs/devel/migration.rst | 531 +++++++++++++++++++++++++++------------
> 1 file changed, 375 insertions(+), 156 deletions(-)
> +
> +General advice for device developers
> +------------------------------------
> +
> +- The migration state saved should reflect the device being modelled rather
> + than the way your implementation works. That way if you change the
> implementation
Three spaces between sentences is unusual.
> +
> +- The migration might happen at an inconvenient point,
> + e.g. right in the middle of the guest reprogramming the device, during
> + guest reboot or shutdown or while the device is waiting for external IO.
> + It's strongly preferred that migrations do not fail in this situation,
> + since in the cloud environment migrations might happen automatically to
> + VMs that the administrator doesn't directly control.
Not for this patch, but is there any mechanism for a device to request
that migration be delayed just long enough for the device to have a
chance to get out of that inconsistent state, rather than having to
migrate the inconvenient state?
> +When we migrate a device, we save/load the state as a series
> +of fields. Some times, due to bugs or new functionality, we need to
Sometimes
> @@ -328,9 +329,12 @@ Sometimes members of the VMState are no longer needed:
>
> - removing them will break migration compatibility
>
> - - making them version dependent and bumping the version will break
> backwards migration compatibility.
> + - making them version dependent and bumping the version will break
> backward migration compatibility.
Is it worth worrying about long lines?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature