[PATCH 0/2] Fix attaching iscsi storage volume
From: Royce Lv <lvroyce@linux.vnet.ibm.com> Iscsi volume fails to attach to vm because of its path is rejected by previous cdrom validate logic, and type 'unknown' forms wrong vm xml This patchset fix the above bugs and form right vm xml in order to start vm. Royce Lv (2): Guest storage: Fix attaching type judgement Guest storage: fix volume format overwrite src/kimchi/model/vmstorages.py | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) -- 1.8.3.2
From: Royce Lv <lvroyce@linux.vnet.ibm.com> When we only supportted cdrom attachment, we check if a cdrom is a valid block device by reading /proc info. Now we added disk attachment support, when a file is neither regular file nor url, we need to see if it is a block device according to its stats. Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- src/kimchi/model/vmstorages.py | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/src/kimchi/model/vmstorages.py b/src/kimchi/model/vmstorages.py index 91c2ab8..f11bcec 100644 --- a/src/kimchi/model/vmstorages.py +++ b/src/kimchi/model/vmstorages.py @@ -20,6 +20,7 @@ import os import re import socket +import stat import string import urlparse @@ -90,16 +91,8 @@ def _check_path(path): if os.path.isfile(path): src_type = 'file' else: - # Check if path is a valid cdrom drive - with open('/proc/sys/dev/cdrom/info') as cdinfo: - content = cdinfo.read() - - cds = re.findall("drive name:\t\t(.*)", content) - if not cds: - raise InvalidParameter("KCHVMSTOR0003E", {'value': path}) - - drives = [os.path.join('/dev', p) for p in cds[0].split('\t')] - if path not in drives: + r_path = os.path.realpath(path) + if not stat.S_ISBLK(os.stat(r_path).st_mode): raise InvalidParameter("KCHVMSTOR0003E", {'value': path}) src_type = 'block' -- 1.8.3.2
As this patch set is ready, I will apply just this one and send a V2 of 2/2 with comments applied. On 08/26/2014 06:50 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
When we only supportted cdrom attachment, we check if a cdrom is a valid block device by reading /proc info. Now we added disk attachment support, when a file is neither regular file nor url, we need to see if it is a block device according to its stats.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- src/kimchi/model/vmstorages.py | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/src/kimchi/model/vmstorages.py b/src/kimchi/model/vmstorages.py index 91c2ab8..f11bcec 100644 --- a/src/kimchi/model/vmstorages.py +++ b/src/kimchi/model/vmstorages.py @@ -20,6 +20,7 @@ import os import re import socket +import stat import string import urlparse
@@ -90,16 +91,8 @@ def _check_path(path): if os.path.isfile(path): src_type = 'file' else:/ - # Check if path is a valid cdrom drive - with open('/proc/sys/dev/cdrom/info') as cdinfo: - content = cdinfo.read() - - cds = re.findall("drive name:\t\t(.*)", content) - if not cds: - raise InvalidParameter("KCHVMSTOR0003E", {'value': path}) - - drives = [os.path.join('/dev', p) for p in cds[0].split('\t')] - if path not in drives: + r_path = os.path.realpath(path) + if not stat.S_ISBLK(os.stat(r_path).st_mode): raise InvalidParameter("KCHVMSTOR0003E", {'value': path})
src_type = 'block'
Applied. Thanks. Regards, Aline Manera
From: Royce Lv <lvroyce@linux.vnet.ibm.com> When vol_info reports unsupported type, such as an iscsi volume with type 'unknown', use 'raw' without overwriting it, this applied to type 'unknown', 'iso' and so on. Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- src/kimchi/model/vmstorages.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/kimchi/model/vmstorages.py b/src/kimchi/model/vmstorages.py index f11bcec..3a656b2 100644 --- a/src/kimchi/model/vmstorages.py +++ b/src/kimchi/model/vmstorages.py @@ -153,7 +153,8 @@ class VMStoragesModel(object): raise InvalidParameter("KCHVMSTOR0015E", {'error': e}) if vol_info['ref_cnt'] != 0: raise InvalidParameter("KCHVMSTOR0016E") - params['format'] = vol_info['format'] + if vol_info['format'] in ["raw", "bochs", "qcow2", "qed"]: + params['format'] = vol_info['format'] params['path'] = vol_info['path'] params['src_type'] = _check_path(params['path']) if (params['bus'] not in HOTPLUG_TYPE -- 1.8.3.2
On 08/26/2014 06:50 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
When vol_info reports unsupported type, such as an iscsi volume with type 'unknown', use 'raw' without overwriting it, this applied to type 'unknown', 'iso' and so on.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- src/kimchi/model/vmstorages.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/kimchi/model/vmstorages.py b/src/kimchi/model/vmstorages.py index f11bcec..3a656b2 100644 --- a/src/kimchi/model/vmstorages.py +++ b/src/kimchi/model/vmstorages.py @@ -153,7 +153,8 @@ class VMStoragesModel(object): raise InvalidParameter("KCHVMSTOR0015E", {'error': e}) if vol_info['ref_cnt'] != 0: raise InvalidParameter("KCHVMSTOR0016E") - params['format'] = vol_info['format'] + if vol_info['format'] in ["raw", "bochs", "qcow2", "qed"]:
From libvirt I got the following types: raw,bochs,qcow,qcow2,qed,vmdk Shouldn't we use all those too?
+ params['format'] = vol_info['format'] params['path'] = vol_info['path'] params['src_type'] = _check_path(params['path']) if (params['bus'] not in HOTPLUG_TYPE
Hi, I tested the patches and they worked when I tried to attach a new iscsi LUN See screenshot attached: - vda is an iSCSI LUN unit:0:0:2 added to vm during its creation - it is a disk of type VOLUME * NOTICE that path is different because I am using the patch I wrote and sent in "[Kimchi-devel] [PATCH] Fix guest disk return when disk is a iscsi volume" . Otherwise, the path would be blank - vdb is an iSCSI LUN unit:0:0:1 added using this patch from Royce Problem is that disks based on iSCSI LUNs are being created differently, generating diferent XMLs. See: 1. <disk type='volume' device='disk'> 2. <driver name='qemu' type='raw'/> 3. <source pool='TEST-ISCSI1' volume='unit:0:0:2' mode='host'/> 4. <target dev='vda' bus='virtio'/> 5. <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> 6. </disk> 7. <disk type='block' device='disk'> 8. <driver name='qemu' type='raw'/> 9. <source dev='/dev/disk/by-id/wwn-0x60000000000000000e00000000010001'/> 10. <target dev='vdb' bus='virtio'/> 11. <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> 12. </disk> 13. <disk type='network' device='cdrom'> 14. <driver name='qemu' type='raw'/> 15. <source protocol='http' name='/pub/fedora/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso'> 16. <host name='204.246.0.137' port='80'/> 17. </source> 18. <target dev='hdc' bus='ide'/> 19. <readonly/> 20. <address type='drive' controller='0' bus='1' target='0' unit='0'/> 21. </disk> So, we need to agree about which xml type are we going to use when attaching an iSCSI Lun: VOLUME or BLOCK ? Once decided, implement similarly when creating VM and when attaching new storage. Then fix the UI if needed. Regards Rodrigo Trujillo On 08/26/2014 06:50 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
Iscsi volume fails to attach to vm because of its path is rejected by previous cdrom validate logic, and type 'unknown' forms wrong vm xml This patchset fix the above bugs and form right vm xml in order to start vm.
Royce Lv (2): Guest storage: Fix attaching type judgement Guest storage: fix volume format overwrite
src/kimchi/model/vmstorages.py | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
On 08/27/2014 04:27 PM, Rodrigo Trujillo wrote:
Hi, I tested the patches and they worked when I tried to attach a new iscsi LUN
See screenshot attached: - vda is an iSCSI LUN unit:0:0:2 added to vm during its creation - it is a disk of type VOLUME * NOTICE that path is different because I am using the patch I wrote and sent in "[Kimchi-devel] [PATCH] Fix guest disk return when disk is a iscsi volume" . Otherwise, the path would be blank - vdb is an iSCSI LUN unit:0:0:1 added using this patch from Royce
Problem is that disks based on iSCSI LUNs are being created differently, generating diferent XMLs. See:
I've just sent a patch to fix this problem and make the volume XML the same in both cases. Check: [Kimchi-devel] [PATCH] Update iSCSI volume XML when creating a VM from an iSCSI pool
1. <disk type='volume' device='disk'> 2. <driver name='qemu' type='raw'/> 3. <source pool='TEST-ISCSI1' volume='unit:0:0:2' mode='host'/> 4. <target dev='vda' bus='virtio'/> 5. <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> 6. </disk> 7. <disk type='block' device='disk'> 8. <driver name='qemu' type='raw'/> 9. <source dev='/dev/disk/by-id/wwn-0x60000000000000000e00000000010001'/> 10. <target dev='vdb' bus='virtio'/> 11. <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> 12. </disk> 13. <disk type='network' device='cdrom'> 14. <driver name='qemu' type='raw'/> 15. <source protocol='http' name='/pub/fedora/releases/20/Live/x86_64/Fedora-Live-Desktop-x86_64-20-1.iso'> 16. <host name='204.246.0.137' port='80'/> 17. </source> 18. <target dev='hdc' bus='ide'/> 19. <readonly/> 20. <address type='drive' controller='0' bus='1' target='0' unit='0'/> 21. </disk>
So, we need to agree about which xml type are we going to use when attaching an iSCSI Lun: VOLUME or BLOCK ? Once decided, implement similarly when creating VM and when attaching new storage. Then fix the UI if needed.
Regards
Rodrigo Trujillo
On 08/26/2014 06:50 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv<lvroyce@linux.vnet.ibm.com>
Iscsi volume fails to attach to vm because of its path is rejected by previous cdrom validate logic, and type 'unknown' forms wrong vm xml This patchset fix the above bugs and form right vm xml in order to start vm.
Royce Lv (2): Guest storage: Fix attaching type judgement Guest storage: fix volume format overwrite
src/kimchi/model/vmstorages.py | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-)
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
lvroyce＠linux.vnet.ibm.com -
Rodrigo Trujillo