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