[Kimchi-devel] [PATCH] Fix guest disk return when disk is a iscsi volume

[Royce Lv]

On 2014年08月27日 02:35, Rodrigo Trujillo wrote:
> On 08/26/2014 05:38 AM, Royce Lv wrote:
>> On 2014年08月26日 12:51, Rodrigo Trujillo wrote:
>>> When a guest has an ISCSI volume attached as disk, backend is not
>>> returning path correctly, it return a blank field. This patch fixes
>>> this problem, returning the path = <iscsi pool> - <volume unit>.
>>>
>>> Signed-off-by: Rodrigo Trujillo <rodrigo.trujillo at linux.vnet.ibm.com>
>>> ---
>>>   src/kimchi/vmdisks.py | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/src/kimchi/vmdisks.py b/src/kimchi/vmdisks.py
>>> index 6012ada..6835172 100644
>>> --- a/src/kimchi/vmdisks.py
>>> +++ b/src/kimchi/vmdisks.py
>>> @@ -53,6 +53,9 @@ def get_vm_disk(dom, dev_name):
>>>                   path = (source.attrib['protocol'] + '://' +
>>>                           host.attrib['name'] + ':' +
>>>                           host.attrib['port'] + source.attrib['name'])
>>> +            # ISCSI, Fibre Channel
>>> +            elif src_type == 'volume':
>>> +                path = source.attrib['pool'] + ' - ' + 
>>> source.attrib['volume']
>>>               else:
>>>                   path = source.attrib[DEV_TYPE_SRC_ATTR_MAP[src_type]]
>>>           # Retrieve storage bus type
>> If a disk is attached from path : POST /vms/vm-name/storages,
>> we just support 3 types of src_type: block, file, and network (as you 
>> can see in vmstorages.py _check_path())
>
> Yes, I have seem this yesterday. Then I open an issue to kimchi:
>     - Kimchi fails when tries to attach new iSCSI volume in edit guest 
> window #408
>     - https://github.com/kimchi-project/kimchi/issues/408
>
> However, I am proposing to fix another problem: The storage return 
> information. See below
>
>>
>> So do you mean if you attached a disk at create time of vm?
>>
>> If I attach iscsi volume to vm as 'block' src_type in runtime
>> and the attached disk in vm xml will be like:
>> <disk type='block' device='disk'>
>> <driver name='qemu' type='raw'/>
>> <source 
>> dev='/dev/disk/by-id/scsi-14945540000000000a9317b0c790140de31c9bfc43cd66411'/>
>> <target dev='vdb' bus='virtio'/>
>> <alias name='virtio-disk1'/>
>> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' 
>> function='0x0'/>
>> </disk>
>
> The problem here is really specific, with iSCSI volumes. When you 
> create a template and assign a iSCSI volume
> in it, the guest generated based on the template will have a disk like:
>
>     <disk type='volume' device='disk'>
>       <driver name='qemu' type='raw'/>
>       <source pool='TEST-ISCSI1' volume='unit:0:0:1' mode='host'/>
>       <target dev='vda' bus='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x05' 
> function='0x0'/>
>     </disk>
>
> Type "volume" is not been handled, so path is returned empty. I am 
> fixing this problem specifically.
If an iscsi target is discovered, and pool and volume can be listed 
through libvirt(even we don't use it), there is a system path under "/dev".
I'm not sure why volume path is empty and we need to fake one ?
>
>
>>
>> So the path of iscsi volume is:
>> <source 
>> dev='/dev/disk/by-id/scsi-14945540000000000a9317b0c790140de31c9bfc43cd66411'/>
>>
>> which you can read from the volume xml.
>> virsh # vol-list --pool iscsi-1
>> Name Path
>> -----------------------------------------
>> unit:0:0:0 
>> /dev/disk/by-id/scsi-14945540000000000a9317b0c790140de31c9bfc43cd66411
>>
>> I think you can report path using this value.
>>
>>
>>
>>
>