Re: [Qemu-devel] migration: Introduce a new "--only-migratable" option

[Ashijeet Acharya]

On Fri, Dec 9, 2016 at 1:29 AM, Dr. David Alan Gilbert
<address@hidden> wrote:
> * Ashijeet Acharya (address@hidden) wrote:
>> Hi Dave,
>>
>> I have added the compatibility of this option for both command line
>> and hotplug via qmp and hmp. Although, please confirm that making use
>> of "device_add" is the only way of hotplugging devices into a QEMU
>> instance.
>
> Hmm; there's obsolete commands like usb_add and netdev_add as well.

Great news is I was finally able to retrieve the DeviceClass of the
device by following the steps just like you advised. So "-usbdevice"
option is now successfully handled and "usb_add" in turn goes through
the same path as well.

Regarding netdev_add, I checked that it only supports those devices
which are all migratable and as you mentioned it has been obsolete now
which means no more devices will be added in the future for this one.
So I believe there might not be a requirement to add compatibility
here.

>
>> With this sorted out, there is one special case left where the device
>> dynamically declares itself 'unmigratable' via migrate_add_blocker. I
>> have a query regarding that which is, what is the preferred action in
>> this scenario? Should I unmount the device or restrict the device from
>> becoming unmigratable in the first place.
>> For example, restrict 9pfs from mounting the filesystem (which you
>> explained previously).
>>
>> Or is there a completely different solution in your mind?
>
> My preferred solution is to stop the device getting into the unmigratable
> state; so whatever function tries to set it should fail (nicely) and
> give an error - e.g the 9pfs should refuse to mount.  I'm not sure
> how hard that is.
>

Alright. I think with the new work posted by John on the list, this
should now be really easy.
I think I can just check if the "--only-migratable" option was used
inside the newly designed "migrate_add_blocker" function by John and
return an error if this is the case. Also your concern about all of it
failing "nicely" will already be handled by John's new work. Although,
I think the error message might change in this case?

Ashijeet

> Dave
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK