Hi James-san and all,
I'm planning to post the latest pvSCSI driver tomorrow evening.
Following are brief explanation of current design and implementation
status.
# I will describe same contents on tomorrow's mail. :-)
-----
As you know, after the post of pvSCSI driver to Xen community on Feb.
18th, we have gotten a lot of requests for improvements. We recognize
that the primary improvements, which affects the basic design of the
pvSCSI driver archtecture, are as follows.
1. Create a "virtual (SCSI) host" on Dom0, and attach it to
appropriate guest domain.
2. Hot-plug a LUN to the virtual host on the Dom0 created by above 1.
The LUN appears and becomes usable immediately on the guest domain.
(By repeating this procedure, you can attach multiple LUNs to the
guest domain.)
3. Support arbitrary SCSI ID mapping between physical host(s) on the
Dom0 and the virtual host. (Physical ID "host:channel:target:lun"
on the Dom0 can be mapped to arbitrary virtual ID
"host:channel:target:lun".)
4. The above 1. to 3. causes needs for "munging" of request and reply
packet on Dom0. (e.g. The LUN list in reply packet for REPORT_LUN
command should be appropriately altered in order to report correct
LUNs actually attached to the virtual host.)
5. Support the Netchannel2, new communication mechanism between Dom0
and guest domain, in order to improve performance.
We have implemented mainly above 1. to 3.
As for 4., we are trying to develop a framework, which can support
various "munging" functions according to user requirements, device
specific functions and so on. (Ideally, the munging function can be
dynamically plugged in, and such like a bitmap table, which controls
invocation of the munging functions, can be specifiable by user.)
How ever, this is a very heavy work, so design and implementation are
still in progress.
And also above 5., we recognize that the source code is not yet
available, therefore current pvSCSI driver does not support it. If it
became available, we would like to replace current communication
mechanism with it.
Jun Kamada
On Wed, 28 May 2008 19:31:58 +1000
"James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:
> >
> > James, if you can find some free time, could you please explain us how
> > this vscsi thing works and how to enable it? Would it also gain us
> some
> > performance, or is for serving other purpose?
> >
>
> pvSCSI was a series of patches posted by Jun Kamada on or around 18th
> Feb 2008 (look for subject "[Patch x/7] pvSCSI driver]. Jun was given a
> heap of feedback in response to those patches and went away to dwell on
> it. A recent post indicated that he would be releasing an updated
> version soon.
>
> xenscsi is a windows frontend driver to the pvSCSI backend driver, and
> allows (via the sg interface) raw scsi devices to be exported from Linux
> to Windows. I am now using it to do test restores of Symantec's Backup
> Exec backups using Symantec's IDR CD. Because the PV drivers are all WDM
> instead of WDF, it's easy enough to make a windows text mode setup
> floppy so you can activate the drivers via F6 when installing Windows.
>
> As for performance, I'm getting between 1-2GB/minute from the tape
> drive, this performance is probably limited by other factors, eg I'm
> still using the qemu harddisk drivers at that stage.
>
> If you had a scsi device (or sas/sata possibly) that you were willing to
> dedicate solely to one domain, xenscsi would allow you to do it. I've
> only tested it on tape drives at the moment. YMMV :)
>
> James
>
> _______________________________________________
> 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
|
Home