Hello!
> If it is truly internal, then avoiding exposing the state to external
> clients is indeed the way to go.
Already done:
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg06262.html, you
should have received it too.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronic
On 10/27/2015 01:08 AM, Pavel Fedin wrote:
> Hello!
>
>> adding new user-visible states
>> has a tendency to break existing clients that aren't prepared for
>> unexpected states (although technically such bugs are in the client - in
>> the past, libvirt used to be one such client, although we've
Hello!
> adding new user-visible states
> has a tendency to break existing clients that aren't prepared for
> unexpected states (although technically such bugs are in the client - in
> the past, libvirt used to be one such client, although we've tried to
> fix it to gracefully ignore unknown stat
On 10/26/2015 06:47 AM, Pavel Fedin wrote:
> This status is set after vm_stop_force_state(), and is telling us that all
> CPUs are stopped, and we are finishing up with the migration.
>
> Also, call notifier_list_notify() when this status is set. This will be
> necessary for ITS live migration on
This status is set after vm_stop_force_state(), and is telling us that all
CPUs are stopped, and we are finishing up with the migration.
Also, call notifier_list_notify() when this status is set. This will be
necessary for ITS live migration on ARM, which will have to dump its state
into guest RAM
