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

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

[Ashijeet Acharya]

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.

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?

Thanks
Ashijeet

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

[Dr. David Alan Gilbert]

* Ashijeet Acharya (ashijeetacharya@gmail.com) 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.

> 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.

Dave

> Thanks
> Ashijeet
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[John Snow]

On 12/08/2016 02:59 PM, Dr. David Alan Gilbert wrote:
> * Ashijeet Acharya (ashijeetacharya@gmail.com) 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.
> 
>> 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.
> 
> Dave
> 
>> Thanks
>> Ashijeet
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

Once upon a time I proposed that "migration_add_blocker" could actually
FAIL. We wound up scrapping the proposal because what I was trying to
achieve at the time wound up being more "policy" than technology, but
maybe it's relevant HERE.

One circumstance in which you might fail to add a migration blocker is
if we are already migrating. Another might be that we have stipulated
that migration must never be blocked, as seems to be your proposal here.

If you allow that call to return an error, you should then be able to
amend all of the workflows that rely on it to also return error. Some
formats and devices may fail to initialize, others may return errors
during runtime as being unable to perform various actions.

maybe this is a tenable approach.

I will rebase my patch and send it out again, it may be useful.

--js

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

[Dr. David Alan Gilbert]

* John Snow (jsnow@redhat.com) wrote:
> 
> 
> On 12/08/2016 02:59 PM, Dr. David Alan Gilbert wrote:
> > * Ashijeet Acharya (ashijeetacharya@gmail.com) 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.
> > 
> >> 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.
> > 
> > Dave
> > 
> >> Thanks
> >> Ashijeet
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> > 
> 
> Once upon a time I proposed that "migration_add_blocker" could actually
> FAIL. We wound up scrapping the proposal because what I was trying to
> achieve at the time wound up being more "policy" than technology, but
> maybe it's relevant HERE.
> 
> One circumstance in which you might fail to add a migration blocker is
> if we are already migrating. Another might be that we have stipulated
> that migration must never be blocked, as seems to be your proposal here.
> 
> If you allow that call to return an error, you should then be able to
> amend all of the workflows that rely on it to also return error. Some
> formats and devices may fail to initialize, others may return errors
> during runtime as being unable to perform various actions.
> 
> maybe this is a tenable approach.
> 
> I will rebase my patch and send it out again, it may be useful.

Yes, that's exactly the behaviour I'm expecting.  In this case
we're not ending up specifying policy since it's a policy selectable
by the user.

Dave

> 
> --js
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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
<dgilbert@redhat.com> wrote:
> * Ashijeet Acharya (ashijeetacharya@gmail.com) 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 / dgilbert@redhat.com / Manchester, UK