Hi,
We do not use qcow images and as I wrote, we're still on 3.2.1 so i
cannot say if 3.4 makes a difference.
However as you can see, except for the added cd command, the script in
3.4 still does the exact same thing as its 3.2.1 counterpart so I'm
doubting this has changed at all?
Now, using qcow images would indeed cause faster deploy times since
there is no real file copying being done. But then you introduce (I
think) the issue of "re-assembling" an image when you want to save it,
download it, back it up, etc...
But again, We're not using 3.4 so if it is solved in there. That is
great news.
And for those that are still using 3.2(.1) my little fix may still be
helpful. :)
Wkr,
Jhon
On 04/18/2012 03:31 PM, Shankhadeep Shome wrote:
Wasn't this addressed in the ON 3.4? You should look into the qcow2
driver in 3.4. If you think its fast now wait till you try the qcow2
backing store driver.. :)
On Wed, Apr 18, 2012 at 3:38 AM, Jhon Masschelein
<[email protected] <mailto:[email protected]>> wrote:
Hi,
In case this has not been mentioned on the list.
FYI: Below I'm talking about non persistent images since persistent
images do not get cloned but symlinked.
If you have a shared storage cloud, the tm_clone script can easily
be improved. before the fix on our cloud, it took about 12 minutes
to launch ten virtual machines with 50GB Images.
After the change, it takes 4 minutes which is quite a nice improvement.
(It now takes about 10 minutes to launch 5TB worth of VM images. :) )
The standard script /usr/lib/one/tm_commands/__shared/tm_clone.sh
will execute the following:
(line 61):
ssh_exec_and_log $DST_HOST \
"cd $DST_DIR; cp -r $SRC_PATH $DST_PATH" \
"Error copying $SRC to $DST"
(We're running 3,2,1 and the "cd $DST_DIR;" is new in 3.4. Not sure
what it is supposed to do but it should not make a difference.)
The problem with the existing script is that the "cp -r $SRC_PATH
$DST_PATH" part is actually reading the whole image from the
fileserver to the opennebula server and then writes it back to a
different directory on the same fileserver.
The result is a very busy opennebula server which becomes
unresponsive and a under-used (NFS) fileserver.
When you make sure that the oneadmin user can ssh to the fileserver,
and that on the fileserver you put a symbolic link that points
/var/lib/one to the exported oneadmin home dir, you can simply
change the cp line to
"ssh $<your_fileserver_here> cp -r $SRC_PATH $DST_PATH"
This will make oneadmin ssh to the fileserver and do the copy
locally on the fileserver.
This puts the load on the fileserver (where it belongs) and makes
the operation very light on the opennebula server which stays
responsive.
Since most shared storage boxes like ours are geared towards fast
IO, this gives a very nice deployment speed increase.
Because the fileserver hostname or ip address needs to be put in the
script, it is difficult to make a patch; this info would need to be
added to a config file somewhere. I leave that up to a volunteer. :)
Hoping this is useful to somebody,
Jhon
--
Jhon Masschelein
Senior Systeemprogrammeur
SARA - HPCV
Science Park 140
1098 XG Amsterdam
T +31 (0)20 592 8099 <tel:%2B31%20%280%2920%20592%208099>
F +31 (0)20 668 3167 <tel:%2B31%20%280%2920%20668%203167>
M +31 (0)6 4748 9328 <tel:%2B31%20%280%296%204748%209328>
E [email protected] <mailto:[email protected]>
http://www.sara.nl
_________________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opennebula.org/__listinfo.cgi/users-opennebula.__org
<http://lists.opennebula.org/listinfo.cgi/users-opennebula.org>
--
Jhon Masschelein
Senior Systeemprogrammeur
SARA - HPCV
Science Park 140
1098 XG Amsterdam
T +31 (0)20 592 8099
F +31 (0)20 668 3167
M +31 (0)6 4748 9328
E [email protected]
http://www.sara.nl
_______________________________________________
Users mailing list
[email protected]
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
