On 05/03/2012 10:05 PM, Li Zhang wrote:
Now, there is only SCSI bus and controller type in libvirt.
And when configuring VSCSI controller, it needs to configure
the spapr-vio bus address type externally. It's a little
inconvenient to configure the controller type.
This patch is to add VSCSI bus type and VSCSI controller type.
And handle with the problems when VSCSI and SCSI devices
working together, by assign the even number to index of
VSCSI controller and odd number to index of SCSI controller.
And when the VSCSI controller is always assigned as SPAPRVIO
bus address type and SCSI controller will be always assigned
as PCI bus address, which is implemented according to the
controllers' type.
So when one disk is based on VSCSI controller, then assign
the bus as 'vscsi', and one right VSCSI controller will be
selected.
If one disk is based on VSCSI controller, the XML file is
as the following:
<disk type='file' device='disk' >
<driver name='qemu' type='raw'/>
<source file='/path/file'/>
<target dev='sda' bus='vscsi'/>
</disk>
VSCSI controllers' configuration in XML file will be like
this:
<controller type='vscsi' index='0'>
</controller>
If one disk is based on 'vscsi', the 'vscsi' bus should be assigned
externally. Otherwise, it will be set as 'scsi' bus according
to the 'sd' target prefix of the disk.
First off, sorry for taking so long to respond.
This isn't exactly what I had in mind when I recommended a libvirt patch.
Change libvirt to add:
<controller type='scsi' index='0'>
<address type='spapr-vio'/>
</controller>
when the guest XML has
<disk type='file' device='disk' >
<driver name='qemu' type='raw'/>
<source file='/path/file'/>
<target dev='sda' bus='scsi'/>
<address type='spapr-vio'/>
</disk>
and the guest XML doesn't already have spapr-vio <controller>.
Then virt-manager etc. only needs to know that for pseries guests, the
default disk should use bus='scsi' and <address type='spapr-vio'/>,
and
libvirt will auto add the correct <controller> for us, like it does for ide,
sata, etc. already.
The patch has obviously weird logic with the even/odd approach, so I think
this approach is better.
Thanks,
Cole