<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> <!--@import url(scrollbar.css); --></STYLE>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<STYLE> BLOCKQUOTE{margin-Top: 0px; margin-Bottom: 0px; margin-Left: 2em} body{FONT-SIZE:12.1pt; COLOR:#001; FONT-FAMILY:宋体,serif;} </STYLE>
<META name=GENERATOR content="MSHTML 8.00.7600.16385"><BASE
target=_blank></HEAD>
<BODY
style="LINE-HEIGHT: 1.3; BORDER-RIGHT-WIDTH: 0px; MARGIN: 12px; BORDER-TOP-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; BORDER-LEFT-WIDTH: 0px"
marginheight="0" marginwidth="0"><STATIONERY>
<DIV><FONT color=#000000 size=3 face=宋体>Currently nova doesn't
limit the disk IO bandwidth in copy_image() method while creating a
new instance, so the other instances on this host may be affected by this high
disk IO consuming operation, and some time-sensitive business(e.g RDS instance
with heartbeat) may be switched between master and slave.</FONT></DIV>
<DIV><FONT color=#000000 size=3></FONT> </DIV>
<DIV><FONT color=#000000 size=3 face=宋体>So can we use the `rsync
--bwlimit=${bandwidth} src dst` command instead of `cp src dst` while copy_image
in create_image() of libvirt driver, the remote image copy operation also
can be limited by `rsync --bwlimit=${bandwidth}` or `scp -l=${bandwidth}`, this
parameter ${bandwidth} can be a new configuration in nova.conf which allow cloud
admin to config it, it's default value is 0 which means no limitation, then
the instances on this host will be not affected while a new instance with
not cached image is creating.</FONT></DIV>
<DIV><FONT color=#000000 size=3></FONT> </DIV>
<DIV><FONT color=#000000 size=3>the example codes:</FONT></DIV>
<DIV><FONT color=#000000 size=3>nova/virt/libvit/utils.py:</FONT></DIV>
<DIV><FONT style="BACKGROUND-COLOR: #ffffff" color=#000000 size=3>diff --git
a/nova/virt/libvirt/utils.py b/nova/virt/libvirt/utils.py<BR>index
e926d3d..5d7c935 100644<BR>--- a/nova/virt/libvirt/utils.py<BR>+++
b/nova/virt/libvirt/utils.py<BR>@@ -473,7 +473,10 @@ def copy_image(src, dest,
host=None):<BR> # sparse
files. I.E. holes will not be written to
DEST,<BR> # rather recreated
efficiently. In addition,
since<BR> # coreutils 8.11,
holes can be read efficiently
too.<BR>- execute('cp', src,
dest)<BR>+ if CONF.mbps_in_copy_image
> 0:<BR>+
execute('rsync', '--bwlimit=%s' % CONF.mbps_in_copy_image * 1024, src,
dest)<BR>+
else:<BR>+
execute('cp', src, dest)<BR>
else:<BR> dest = "%s:%s" %
(host, dest)<BR> # Try rsync
first as that can compress and create sparse dest files.<BR>@@ -484,11 +487,22
@@ def copy_image(src, dest,
host=None):<BR>
# Do a relatively light weight test first, so that
we<BR> #
can fall back to scp, without having run out of
space<BR>
# on the destination for
example.<BR>-
execute('rsync', '--sparse', '--compress', '--dry-run', src,
dest)<BR>+ if
CONF.mbps_in_copy_image >
0:<BR>+
execute('rsync', '--sparse', '--compress',
'--dry-run',<BR>+
'--bwlimit=%s' % CONF.mbps_in_copy_image * 1024, src,
dest)<BR>+
else:<BR>+
execute('rsync', '--sparse', '--compress', '--dry-run', src,
dest)<BR> except
processutils.ProcessExecutionError:<BR>-
execute('scp', src,
dest)<BR>+ if
CONF.mbps_in_copy_image >
0:<BR>+
execute('scp', '-l', '%s' % CONF.mbps_in_copy_image * 1024 * 8, src,
dest)<BR>+
else:<BR>+
execute('scp', src, dest)<BR>
else:<BR>-
execute('rsync', '--sparse', '--compress', src,
dest)<BR>+ if
CONF.mbps_in_copy_image >
0:<BR>+
execute('rsync', '--sparse',
'--compress',<BR>+
'--bwlimit=%s' % CONF.mbps_in_copy_image * 1024, src,
dest)<BR>+
else:<BR>+
execute('rsync', '--sparse', '--compress', src, dest)</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV align=left><FONT color=#c0c0c0 size=2
face=Verdana>2014-02-14</FONT></DIV><FONT size=2 face=Verdana>
<HR style="WIDTH: 122px; HEIGHT: 2px" id=SignNameHR align=left SIZE=2>
</FONT>
<DIV><FONT color=#c0c0c0 size=2 face=Verdana><SPAN
id=_FlashSignName>Wangpan</SPAN></FONT></DIV></STATIONERY></BODY></HTML>