Re: [Xen-devel] [RFC][PATCH] Enhance XenAPI for pvSCSI

[Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>]

Hi Yosuke and XenAPI developers,

Thanks for your opinion. 
I was able to understand your opinion enough, so I believe 
that "DSCSI" is better than "VSCSI".  But I'd like to hear 
opinions from XenAPI developers except you. 

   Is prefix of half-virtualized "D" or "V"?

Best regards,
 Kan

Mon, 08 Sep 2008 14:00:47 +0900, Yosuke Iwamatsu wrote:

>Jun Kamada wrote:
>> Hi Iwamatsu-san,
>> 
>> The pvSCSI driver provides virtualized SCSI tree to guest domains. 
>> (You can specify arbitrary IDs (Host:Channel:Target:Lun) mapping 
>> between Dom0 and the guests.)
>> 
>> In addition to that, some SCSI commands, for example REPORT_LUN, may 
>> be emulated on backend driver but simply passthroughed to physical
>> device.
>> 
>> So, class name 'VSCSI' is appropriate, in my personal opinion.
>
>The guest sees a virtualized scsi host, a virtualized scsi tree but
>endpoint devices (luns) themselves are not virtualized, right?
>I'm under an impression that pvscsi is similer to pass-through pci
>and 'V' prefix is not appropriate for these half-virtualized,
>half-physical devices.
>
>Below is my idea of naming xen-api classes:
>a. If the device is trully virtualized, give 'V' prefix (VIF, VBD etc).
>    For example, a VIF has virtual mac address, virtual vendor name
>    and virtual device name and the guest see nothing about physical nic
>    devices. Actually, it is possible to create VIF devices even if the
>    host doesn't have physical network devices.
>b. If the device is half-virtualized, give 'D' prefix.
>    When using pass-through pci, host controllers, device trees, config
>    spaces might be virtualized but the guest see physical device
>    information like device id and vendor id, and directly access to
>    registers. The host, of course, has to have physical devices and
>    the device will be occupied while it is used by a guest.
>
>I don't know details about pvscsi, but perphaps we had better
>categorize it as b.
>
>Thanks,
>-- Yosuke
>
>> 
>> Best regards,
>> 
>> 
>> On Fri, 05 Sep 2008 17:52:42 +0900
>> Yosuke Iwamatsu <y-iwamatsu@xxxxxxxxxxxxx> wrote:
>> 
>>> Hi,
>>>
>>> Masaki Kanno wrote:
>>>> Hi,
>>>>
>>>> I would like to enhance XenAPI for pvSCSI. 
>>>> At the beginning, I updated only the document of XenAPI.  I'm going 
>>>> to implement XenAPI of pvSCSI along the document.  Could you comment?
>>>>
>>>> The following classes and RPCs are added by the enhancement. 
>>>>  Classes:
>>>>   - VSCSI class
>>>>      This is a class for virtual SCSI devices.
>>> It's nice to keep xen-api updated with new features :-)
>>> One thing I want to point out is about the class name.
>>> I think 'DSCSI' (direct scsi) is appropriate rather than 'VSCSI',
>>> because pvSCSI driver doesn't really provide virtual scsi luns but
>>> passes through scsi commands to real scsi luns, as far as I understand.
>>>
>>> Regards,
>>> -- Yosuke Iwamatsu
>>>
>>>>   - PSCSI class
>>>>      This is a class for physical SCSI devices.
>>>>
>>>>  RPCs:
>>>>   - VSCSI class
>>>>    -- get_all
>>>>        A list of all VSCSIs known to the system is gotten.
>>>>    -- get_uuid
>>>>        An UUID of the VSCSI is gotten.
>>>>    -- get_VM
>>>>        A VM ref of the VSCSI is gotten.
>>>>    -- get_PSCSI
>>>>        A PSCSI ref of the VSCSI is gotten.
>>>>    -- get_virtual_host
>>>>        A virtual host number of the VSCSI is gotten.
>>>>    -- get_virtual_channel
>>>>        A virtual channel number of the VSCSI is gotten.
>>>>    -- get_virtual_target
>>>>        A virtual target number of the VSCSI is gotten.
>>>>    -- get_virtual_lun
>>>>        A virtual logical unit number of the VSCSI is gotten.
>>>>    -- get_virtual_HCTL
>>>>        A virtual HCTL (string of "<host>:<channel>:<target>:<lun>") 
>>>>        of the VSCSI is gotten.
>>>>    -- create
>>>>        A new VSCSI instance is created.
>>>>    -- destroy
>>>>        The VSCSI instance is destroyed.
>>>>    -- get_by_uuid
>>>>        A VSCSI ref of the UUID is gotten.
>>>>    -- get_record
>>>>        A VSCSI record of the VSCSI is gotten.
>>>>
>>>>   - PSCSI class
>>>>    -- get_all
>>>>        A list of all PSCSIs known to the system is gotten.
>>>>    -- get_uuid
>>>>        An UUID of the PSCSI is gotten.
>>>>    -- get_host
>>>>        A host ref of the PSCSI is gotten.
>>>>    -- get_physical_host
>>>>        A physical host number of the PSCSI is gotten.
>>>>    -- get_physical_channel
>>>>        A physical channel number of the PSCSI is gotten.
>>>>    -- get_physical_target
>>>>        A physical target number of the PSCSI is gotten.
>>>>    -- get_physical_lun
>>>>        A physical logical unit number of the PSCSI is gotten.
>>>>    -- get_physical_HCTL
>>>>        A physical HCTL (string of "<host>:<channel>:<target>:<lun>") 
>>>>        of the PSCSI is gotten.
>>>>    -- get_vendor_name
>>>>        A vendor name of the PSCSI is gotten.
>>>>    -- get_model
>>>>        A model name of the PSCSI is gotten.
>>>>    -- get_type_id
>>>>        An ID of device types of the PSCSI is gotten. (If disk, the ID 
>>>>        is 0.  If tape, the ID is 1.)
>>>>    -- get_type
>>>>        A device type string of the PSCSI is gotten.
>>>>    -- get_sg_name
>>>>        A SCSI generic (sg) device name of the PSCSI is gotten.
>>>>    -- get_revision
>>>>        A revision string of the PSCSI is gotten.
>>>>    -- get_scsi_id
>>>>        A SCSI ID string of the PSCSI is gotten. The string is a result 
>>>>        of 'scsi_id -gu -s'.
>>>>    -- get_scsi_level
>>>>        A SCSI level of the PSCSI is gotten.
>>>>    -- get_by_uuid
>>>>        A PSCSI ref of the UUID is gotten.
>>>>    -- get_record
>>>>        A PSCSI record of the PSCSI is gotten.
>>>>
>>>>   - VM class
>>>>    -- get_VSCSIs
>>>>        VSCSI refs of the VM are gotten.
>>>>
>>>>   - host class
>>>>    -- get_PSCSIs
>>>>        PSCSI refs of the host are gotten.
>>>>
>>>>
>>>> Signed-off-by: Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>
>>>>
>>>> Best regards,
>>>>  Kan
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Xen-devel mailing list
>>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-devel
>>>
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>>> http://lists.xensource.com/xen-devel
>> 
>> 
>> -----
>> Jun Kamada
>> Linux Software Development Div.
>> Server Systems Unit
>> Fujitsu Ltd.
>> kama@xxxxxxxxxxxxxx
>> 
>> 
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel