From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yosuke Iwamatsu Subject: Re: [Xen-devel] [RFC][PATCH] Enhance XenAPI for pvSCSI Date: Mon, 08 Sep 2008 14:00:47 +0900 Message-ID: <48C4B17F.2040104@ab.jp.nec.com> References: <41C90D924C4601kanno.masaki@jp.fujitsu.com> <48C0F35A.4080107@ab.jp.nec.com> <20080908112241.8179.EB2C8575@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080908112241.8179.EB2C8575-+CUm20s59erQFUHtdCDX3A@public.gmane.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org Errors-To: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org To: Jun Kamada Cc: t.horikoshi-+CUm20s59erQFUHtdCDX3A@public.gmane.org, xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org, xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org List-Id: xen-devel@lists.xenproject.org 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 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 ":::") >>> 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 ":::") >>> 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 >>> >>> Best regards, >>> Kan >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org >>> http://lists.xensource.com/xen-devel >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org >> http://lists.xensource.com/xen-devel > > > ----- > Jun Kamada > Linux Software Development Div. > Server Systems Unit > Fujitsu Ltd. > kama-+CUm20s59erQFUHtdCDX3A@public.gmane.org > >