Il 06/07/2012 05:38, Nicholas A. Bellinger ha scritto: > So I imagine that setting inquiry/vpd/mode via configfs attribs to match > whatever the guest wants to see (or expects to see) can be enabled > via /sys/kernel/config/target/core/$HBA/$DEV/[wwn,attrib]/ easily to > whatever is required. > > However, beyond basic SCSI WWN related bits, I would avoid trying to > match complex SCSI target state between the in-kernel patch and QEMU > SCSI. Agreed. It should just be the bare minimum to make stable /dev/disk paths, well, stable between the two backends. >>> so that it is not possible to migrate one to the other. >> >> Migration between different backend types does not seem all that useful. >> The general rule is you need identical flags on both sides to allow >> migration, and it is not clear how valuable it is to relax this >> somewhat. > > I really need to learn more about how QEMU Live migration works wrt to > storage before saying how this may (or may not) work. vhost-scsi live migration should be easy to fix. You need some ioctl or eventfd mechanism to communicate to userspace that there is no pending I/O, but you need that anyway also for other operations (as simple as stopping the VM: QEMU guarantees that the "stop" monitor command returns only when there is no outstanding I/O). What worries me most is: 1) the amount of functionality that is lost with vhost-scsi, especially the new live operations that we're adding to QEMU; 2) whether any hook we introduce in the QEMU block layer will cause problems down the road when we set to fix the existing virtio-blk/virtio-scsi-qemu performance problems. This is the reason why I'm reluctant to merge the QEMU bits. The kernel bits are self-contained and are much less problematic. It may well be that _the same_ (or very similar) hooks will be needed by both tcm_vhost and high-performance userspace virtio backends. This would of course remove the objection. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
