qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] migration: Introduce a new "--only-migratable" option
Date: Fri, 9 Dec 2016 09:10:42 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

* John Snow (address@hidden) wrote:
> 
> 
> On 12/08/2016 02:59 PM, Dr. David Alan Gilbert 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.
> > 
> >> 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 / address@hidden / 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 / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]