Hi MST, Paolo & Co, On Mon, 2013-01-28 at 15:39 +0200, Michael S. Tsirkin wrote: > 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. > > >> So what's the verdict here..? Shall I respin the vhost-scsi patches against qemu.git HEAD to make it in before Friday's cutoff for v1.4..? Also, I'm not exactly sure what's involved with a vhost=on/off frontend option discussed above, so if you or Paolo could handle this bit it would be very helpful. :) --nab -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html