Re: [Qemu-devel] Anyone seeing huge slowdown launching qemu with Linux 2.6.35?

[Alexander Graf]

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