On Mon, Jan 28, 2013 at 02:33:44PM +0100, Paolo Bonzini wrote:
> Il 28/01/2013 14:36, Michael S. Tsirkin ha scritto:
> > On Mon, Jan 28, 2013 at 02:29:23PM +0100, Paolo Bonzini wrote:
> >> Il 28/01/2013 14:11, Michael S. Tsirkin ha scritto:
> >>>> I asked for a standalone device because the configuration mechanism
> >>>> (configfs vs. command-line) and the feature set are completely
> >>>> different.  Unlike virtio-net, it's not possible to switch one to the
> >>>> other at run time.
> >>>
> >>> Exactly the same applies to any other frontend option.
> >>> For example if you have two qemu instances with
> >>> different num_queues values you can not migrate one
> >>> to the other.
> >>> So in this sense it is not different from any other
> >>> frontend option, right?
> >>
> >> Indeed, in this sense it is not.
> >>
> >> Actually in this case migrating one to the other could succeed, and make
> >> all disks disappear on the destination (because of the different
> >> configuration mechanism).  That however could be overcome with vhost=on
> >> registering a migration blocker.
> > 
> > Or better add a subsection if vhost is set: vhost=on to vhost=on
> > can migrate, right?
> 
> I think it's not yet supported by the kernel.  You have no guarantee
> that I/O is quiescent at the time the VM starts on the destination.
> You'd need a ioctl to do the equivalent of bdrv_drain_all().
> 
> Once you have that, a subsection would do the job, yes.
> 
> Paolo

OK once that's in it would be easy to probe for.

> >> I won't really block the patch with the vhost=on/off frontend option if
> >> it is properly done (e.g. the QEMU SCSI bus should not be created for
> >> vhost=on) and minimally invasive to the non-vhost code.
> >>
> >> Paolo

Reply via email to