On 02/22/2017 09:19 AM, Lin Ma wrote: > Hi Hannes, > >>>> Hannes Reinecke <h...@suse.de> 2017/2/16 星期四 下午 5:56 >>> >>On 02/16/2017 09:39 AM, Paolo Bonzini wrote: >>> >>> >>> On 16/02/2017 08:16, Lin Ma wrote: >>>>> What are the benefits of having FC access from the guest? >>>> >>>> Actually, I havn't dug it too much, Just thought that from > virtualization's >>>> perspective, when interact with FC storage, having complete FC access >>>> from the guest is the way it should use. >>> >>> How much of this requires a completely new spec? Could we get enough of >>> the benefit (e.g. the ability to issue rescans or LIPs on the host) by >>> extending virtio-scsi? >>> >> I guess I'd need to chime in with my favourite topic :-) >> >> Initially I really would go with extending the virtio-scsi spec, as >> 'real' virtio-fc suffers from some issues: >> While it's of course possible to implement a full fc stack in qemu >> itself, it's not easily possible assign 'real' FC devices to the guest. >> Problem here is that any virtio-fc would basically have to use the >> standard FC frame format for virtio itself, but all 'real' FC HBAs >> (excluding FCoE drivers) do _not_ allow access to the actual FC frames, >> but rather present you with a 'cooked' version of them. >> So if you were attempting to pass FC devices to the guest you would have >> to implement yet-another conversion between raw FC frames and the >> version the HBA would like. >> And that doesn't even deal with the real complexity like generating >> correct OXID/RXIDs etc. >> >> So initially I would propose to update the virtio spec to include: >> - Full 64bit LUNs >> - A 64bit target port ID (well, _actually_ it should be a SCSI-compliant >> target port ID, but as this essentially is a free text field I'd >> restrict it to something sensible) >> For full compability we'd also need a (64-bit) initiator ID, but that is >> essentially a property of the virtio queue, so we don't need to transmit >> it with every command; once during queue setup is enough. >> And if we restrict virtio-scsi to point-to-point topology we can even >> associate the target port ID with the virtio queue, making >> implementation even easier. >> I'm not sure if that is a good idea long-term, as one might want to >> identify an NPIV host with a virtio device, in which case we're having a >> 1-M topology and that model won't work anymore. >> >> To be precise: >> >> I'd propose to update >> >> struct virtio_scsi_config >> with a field 'u8 initiator_id[8]' >> >> and >> >> struct virtio_scsi_req_cmd >> with a field 'u8 target_id[8]' >> >> and do away with the weird LUN remapping qemu has nowadays. > Does it mean we dont need to provide '-drive' and '-device scsi-hd' > option in qemu command line? so the guest can get its own LUNs > through fc switch, right? > No, you still would need that (at least initially). But with the modifications above we can add tooling around qemu to establish the correct (host) device mappings. Without it we a) have no idea from the host side which devices should be attached to any given guest b) have no idea from the guest side what the initiator and target IDs are; which will get _really_ tricky if someone decides to use persistent reservations from within the guest...
For handling NPIV proper we would need to update qemu a) locate the NPIV host based on the initiator ID from the guest b) stop exposing the devices attached to that NPIV host to the guest c) establish a 'rescan' routine to capture any state changes (LUN remapping etc) of the NPIV host. But having the initiator and target IDs in virtio scsi is a mandatory step before we can attempt anything else. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
