On 04.08.2010, at 18:49, Anthony Liguori wrote: > On 08/04/2010 11:48 AM, Alexander Graf wrote: >> On 04.08.2010, at 18:46, Anthony Liguori wrote: >> >> >>> On 08/04/2010 11:44 AM, Avi Kivity wrote: >>> >>>> On 08/04/2010 03:53 PM, Anthony Liguori wrote: >>>> >>>>> So how do we enable support for more than 20 disks? I think a >>>>> virtio-scsi is inevitable.. >>>>> >>>> Not only for large numbers of disks, also for JBOD performance. If you >>>> have one queue per disk you'll have low queue depths and high interrupt >>>> rates. Aggregating many spindles into a single queue is important for >>>> reducing overhead. >>>> >>> Right, the only question is, to you inject your own bus or do you just >>> reuse SCSI. On the surface, it seems like reusing SCSI has a significant >>> number of advantages. For instance, without changing the guest's drivers, >>> we can implement PV cdroms or PC tape drivers. >>> >> What exactly would keep us from doing that with virtio-blk? I thought that >> supports scsi commands already. >> > > I think the toughest change would be making it appear as a scsi device within > the guest. You could do that to virtio-blk but it would be a flag day as > reasonable configured guests will break. > > Having virtio-blk device show up as /dev/vdX was a big mistake. It's been > nothing but a giant PITA. There is an amazing amount of software that only > looks at /dev/sd* and /dev/hd*.
I completely agree and yes, we should move in that direction IMHO. I don't see why virtio-blk should be any different from megasas for example. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
