Bug #4627
onetemplate instantiate --persistent problem with image SOURCE
Status: | Pending | Start date: | 07/08/2016 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | - | |||
Resolution: | Pull request: | |||
Affected Versions: | OpenNebula 5.0 |
Description
I run my experiments with an ttylinux instance. When I instantiate ttylinux template to be persistent, I get VM like this:
<VM> <ID>712</ID> <UID>0</UID> <GID>0</GID> <UNAME>oneadmin</UNAME> <GNAME>oneadmin</GNAME> <NAME>test</NAME> <PERMISSIONS> <OWNER_U>1</OWNER_U> <OWNER_M>1</OWNER_M> <OWNER_A>0</OWNER_A> <GROUP_U>0</GROUP_U> <GROUP_M>0</GROUP_M> <GROUP_A>0</GROUP_A> <OTHER_U>0</OTHER_U> <OTHER_M>0</OTHER_M> <OTHER_A>0</OTHER_A> </PERMISSIONS> <LAST_POLL>1467967495</LAST_POLL> <STATE>3</STATE> <LCM_STATE>39</LCM_STATE> <PREV_STATE>3</PREV_STATE> <PREV_LCM_STATE>39</PREV_LCM_STATE> <RESCHED>0</RESCHED> <STIME>1467966455</STIME> <ETIME>0</ETIME> <DEPLOY_ID/> <MONITORING> <CPU><![CDATA[0.0]]></CPU> <MEMORY><![CDATA[0]]></MEMORY> </MONITORING> <TEMPLATE> <AUTOMATIC_DS_REQUIREMENTS><![CDATA["CLUSTERS/ID" = 0]]></AUTOMATIC_DS_REQUIREMENTS> <AUTOMATIC_REQUIREMENTS><![CDATA[(CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES)]]></AUTOMATIC_REQUIREMENTS> <CLONING_TEMPLATE_ID><![CDATA[36]]></CLONING_TEMPLATE_ID> <CONTEXT> <DISK_ID><![CDATA[1]]></DISK_ID> <NETWORK><![CDATA[YES]]></NETWORK> <SSH_PUBLIC_KEY><![CDATA[ssh-rsa dfgfdg+xLmwTzNe75P1dEjPaGU4j5dnGYml9huSnL5ToNqlCJzKshmnFGz2y3fz4ZWcsnwWIFFQESOSVjM PwYEjJ0dUhOxbjd6ce0bkA0KdyfyXZ5wWi/CIfrzYaUkniZAa6rx6HJBP/9WOAXJMuslPuN+aKXxasqAubilNimqrjGy3XWb3+deJznF9SRw9ZXjkYis3+O8nfvlJl0xD9X7n1W8BdUJFd9eRqvefNdTYHgl7qsPum+AuG4Qu0h1trI4 V8Bc4YEDfPdVBxWXXTBgpKdIUeGND1Vi5xhmApsKYSJgSiauHrT2KeAtnaf gggggg]]></SSH_PUBLIC_KEY> <TARGET><![CDATA[hdb]]></TARGET> </CONTEXT> <CPU><![CDATA[0.1]]></CPU> <DISK> <CLONE><![CDATA[NO]]></CLONE> <CLONE_TARGET><![CDATA[SELF]]></CLONE_TARGET> <CLUSTER_ID><![CDATA[0]]></CLUSTER_ID> <DATASTORE><![CDATA[emc-fc]]></DATASTORE> <DATASTORE_ID><![CDATA[106]]></DATASTORE_ID> [20/81] <DEV_PREFIX><![CDATA[hd]]></DEV_PREFIX> <DISK_ID><![CDATA[0]]></DISK_ID> <DISK_SNAPSHOT_TOTAL_SIZE><![CDATA[0]]></DISK_SNAPSHOT_TOTAL_SIZE> <IMAGE><![CDATA[test-disk-0]]></IMAGE> <IMAGE_ID><![CDATA[287]]></IMAGE_ID> <IMAGE_STATE><![CDATA[10]]></IMAGE_STATE> <LN_TARGET><![CDATA[NONE]]></LN_TARGET> <PERSISTENT><![CDATA[YES]]></PERSISTENT> <READONLY><![CDATA[NO]]></READONLY> <SAVE><![CDATA[YES]]></SAVE> <SIZE><![CDATA[40]]></SIZE> <SOURCE><![CDATA[-]]></SOURCE> <TARGET><![CDATA[hda]]></TARGET> <TM_MAD><![CDATA[emc]]></TM_MAD> <TYPE><![CDATA[BLOCK]]></TYPE> </DISK> <GRAPHICS> <LISTEN><![CDATA[0.0.0.0]]></LISTEN> <PORT><![CDATA[6612]]></PORT> <TYPE><![CDATA[vnc]]></TYPE> </GRAPHICS> <MEMORY><![CDATA[128]]></MEMORY> <TEMPLATE_ID><![CDATA[39]]></TEMPLATE_ID> <VMID><![CDATA[712]]></VMID> </TEMPLATE> <USER_TEMPLATE> <ERROR><![CDATA[Fri Jul 8 10:46:07 2016 : Error executing image transfer script: Error dropping device - on kvasi.k13132.local]]></ERROR> <LOGO><![CDATA[images/logos/linux.png]]></LOGO> </USER_TEMPLATE> <HISTORY_RECORDS> <HISTORY> <OID>712</OID> <SEQ>0</SEQ> <HOSTNAME>kvasi.k13132.local</HOSTNAME> <HID>7</HID> <CID>0</CID> <STIME>1467966504</STIME> <ETIME>1467967495</ETIME> <VM_MAD><![CDATA[kvm]]></VM_MAD> <TM_MAD><![CDATA[ssh]]></TM_MAD> <DS_ID>0</DS_ID> <PSTIME>1467966504</PSTIME> <PETIME>1467967495</PETIME> <RSTIME>0</RSTIME> <RETIME>0</RETIME> <ESTIME>0</ESTIME> <EETIME>0</EETIME> <REASON>2</REASON> <ACTION>14</ACTION> </HISTORY> <HISTORY> <OID>712</OID> <SEQ>1</SEQ> <HOSTNAME>kvasi.k13132.local</HOSTNAME> <HID>7</HID> <CID>0</CID> <STIME>1467967584</STIME> <ETIME>0</ETIME> <VM_MAD><![CDATA[kvm]]></VM_MAD> <TM_MAD><![CDATA[ssh]]></TM_MAD> <DS_ID>0</DS_ID> <PSTIME>1467967584</PSTIME> <PETIME>0</PETIME> <RSTIME>0</RSTIME> <RETIME>0</RETIME> <ESTIME>0</ESTIME> <EETIME>0</EETIME> <REASON>0</REASON> <ACTION>0</ACTION> </HISTORY> </HISTORY_RECORDS> </VM>
As you can see this XML addresses image 287 for disk.0. However, this newly created image has XML like this:
<IMAGE> <ID>287</ID> <UID>0</UID> <GID>0</GID> <UNAME>oneadmin</UNAME> <GNAME>oneadmin</GNAME> <NAME>test-disk-0</NAME> <PERMISSIONS> <OWNER_U>1</OWNER_U> <OWNER_M>1</OWNER_M> <OWNER_A>0</OWNER_A> <GROUP_U>0</GROUP_U> <GROUP_M>0</GROUP_M> <GROUP_A>0</GROUP_A> <OTHER_U>0</OTHER_U> <OTHER_M>0</OTHER_M> <OTHER_A>0</OTHER_A> </PERMISSIONS> <TYPE>0</TYPE> <DISK_TYPE>2</DISK_TYPE> <PERSISTENT>1</PERSISTENT> <REGTIME>1467966455</REGTIME> <SOURCE><![CDATA[-]]></SOURCE> <PATH><![CDATA[101]]></PATH> <FSTYPE><![CDATA[raw]]></FSTYPE> <SIZE>40</SIZE> <STATE>8</STATE> <RUNNING_VMS>1</RUNNING_VMS> <CLONING_OPS>0</CLONING_OPS> <CLONING_ID>-1</CLONING_ID> <TARGET_SNAPSHOT>-1</TARGET_SNAPSHOT> <DATASTORE_ID>106</DATASTORE_ID> <DATASTORE>emc-fc</DATASTORE> <VMS> <ID>712</ID> </VMS> <CLONES/> <APP_CLONES/> <TEMPLATE> <DEV_PREFIX><![CDATA[hd]]></DEV_PREFIX> <FORMAT><![CDATA[raw]]></FORMAT> <FROM_APP><![CDATA[0]]></FROM_APP> <FROM_APP_NAME><![CDATA[ttylinux - kvm]]></FROM_APP_NAME> <FSTYPE><![CDATA[raw]]></FSTYPE> <MD5><![CDATA[04c7d00e88fa66d9aaa34d9cf8ad6aaa]]></MD5> </TEMPLATE> <SNAPSHOTS/> </IMAGE>
Source attribute is empty and Path addresses the origin Image. The problem is, by that time a new LUN is already created and has ID 102:
LUN 101: 60:06:01:60:84:E1:20:00:34:E3:8B:FD:E1:44:E6:11 has size 40MB LUN 102: 60:06:01:60:84:E1:20:00:F8:88:C9:15:E6:44:E6:11 has size 40MB
All this results into wrong call for LN:
Fri Jul 8 10:29:51 2016 [Z0][TM][I]: Command execution fail: /var/lib/one/remotes/tm/emc/ln kvasi.k13132.local:- kvasi.k13132.local:/var/lib/one//datastores/0/712/disk.0 712 106 Fri Jul 8 10:29:51 2016 [Z0][TM][I]: dirname: invalid option -- '/' Fri Jul 8 10:29:51 2016 [Z0][TM][I]: Try 'dirname --help' for more information.
Due tu '-' in place of SOURCE the arg_path does not wrong properly!
I ran into this problem after ONE upgrade to 5.0.1 (I think this is problem of 5.0 as well) and verifying compliance of our in-house driver: https://github.com/k13132/addon-fc-emc
History
#1 Updated by Miloš Kozák almost 5 years ago
I am taking this back because it was error in my driver: https://github.com/k13132/addon-fc-emc/commit/d037e06f3a276be2f341b4e13b90f906f26f2bcb
Nevertheless, what is the purpose of cloning_id. I tried to clone image in datastore and it works now as well...
#2 Updated by Anton Todorov almost 5 years ago
Hi,
Here is a comment in the sources regarding the "clonning_id": "the ID of the image we are cloning this one from (if any)"
https://github.com/OpenNebula/one/blob/master/include/Image.h#L274
I am also not using it ;)
Kind Regards,
Anton Todorov
#3 Updated by Ruben S. Montero almost 5 years ago
SOURCE comes from the driver, it is supposed to be a driver specific source string that identifies the disk. It should be returned when the image is created by the driver. I think this may be an issue with your driver...