WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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