Re: [openstack-dev] [nova]resize
I test after i change nova-resize code.
configuration:
controler:1
computenode:3
storage: nfs,
before nova resize is changed
Task fdc67dfe-b182-4450-8e85-10085626acab is finished.
test scenario NovaServers.resize_server
args position 0
args values:
{u'args': {u'confirm': True,
u'flavor': u'5a180f8a-51e9-4621-a9f9-7332253e0b32',
u'image': u'95be464a-ddac-4332-9c14-3c9bc4156c86',
u'to_flavor': u'90ff2ce2-e116-4295-b33a-13f54a26d495'},
u'context': {u'users': {u'concurrent': 30,
u'tenants': 1,
u'users_per_tenant': 1}},
u'runner': {u'concurrency': 5,
u'timeout': 2000,
u'times': 10,
u'type': u'constant'}}
+-+---+---+---+---+---+-+---+
| action | min (sec) | avg (sec) | max (sec) | 90 percentile | 95
percentile | success | count |
+-+---+---+---+---+---+-+---+
| nova.boot_server| 11.052| 94.3 | 167.309 | 167.108 |
167.208 | 100.0% | 10|
| nova.delete_server | 8.884 | 23.542| 96.072| 31.738|
63.905| 100.0% | 10|
| nova.resize | 301.313 | 353.936 | 448.779 | 447.586 |
448.183 | 100.0% | 10|
| nova.resize_confirm | 2.425 | 20.242| 145.639 | 26.322|
85.981| 100.0% | 10|
| total | 466.888 | 492.02| 512.294 | 508.277 |
510.285 | 100.0% | 10|
+-+---+---+---+---+---+-+---+
after nova-resize code is changed
Task cd7a3d71-ccae-481b-aaa3-49902ad0da08 is finished.
test scenario NovaServers.resize_server
args position 0
args values:
{u'args': {u'confirm': True,
u'flavor': u'5a180f8a-51e9-4621-a9f9-7332253e0b32',
u'image': u'95be464a-ddac-4332-9c14-3c9bc4156c86',
u'to_flavor': u'90ff2ce2-e116-4295-b33a-13f54a26d495'},
u'context': {u'users': {u'concurrent': 30,
u'tenants': 1,
u'users_per_tenant': 1}},
u'runner': {u'concurrency': 5,
u'timeout': 2000,
u'times': 10,
u'type': u'constant'}}
+-+---+---+---+---+---+-+---+
| action | min (sec) | avg (sec) | max (sec) | 90 percentile | 95
percentile | success | count |
+-+---+---+---+---+---+-+---+
| nova.boot_server| 13.997| 16.314| 18.858| 17.82 |
18.339| 100.0% | 10|
| nova.delete_server | 6.593 | 8.877 | 10.85 | 10.777|
10.814| 100.0% | 10|
| nova.resize | 16.072| 19.147| 22.807| 22.798|
22.803| 100.0% | 10|
| nova.resize_confirm | 2.459 | 5.368 | 10.618| 6.949 |
8.783 | 100.0% | 10|
| total | 43.034| 49.707| 55.565| 53.537|
54.551| 100.0% | 10|
+-+---+---+---+---+---+-+---+
But it is just rough change, some point needs to put into consideration.
What i do is no backing file when using shared storage,
use qcow2 to resize directly rather than change the disk to raw then to qcow2.
At 2014-07-25 10:09:09, Tian, Shuangtai shuangtai.t...@intel.com wrote:
Agree with you now
-Original Message-
From: fdsafdsafd [mailto:jaze...@163.com]
Sent: Thursday, July 24, 2014 5:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova]resize
No.
before L5156, we convert it from qcow2 to qcow2, in which it strips backing
file.
I think here, we should wirte like this:
if info['type'] == 'qcow2' and info['backing_file']:
if shared_storage:
utils.execute('cp', from_path, img_path)
else:
tmp_path = from_path + _rbase
# merge backing file
utils.execute('qemu-img', 'convert', '-f', 'qcow2',
'-O', 'qcow2', from_path, tmp_path)
libvirt_utils.copy_image(tmp_path, img_path, host=dest)
utils.execute('rm', '-f', tmp_path)
else: # raw or qcow2 with no backing file
libvirt_utils.copy_image(from_path, img_path, host=dest)
At 2014-07-24 05:02:39, Tian, Shuangtai shuangtai.t
Re: [openstack-dev] [nova]resize
On 24 July 2014 20:38, Vishvananda Ishaya vishvana...@gmail.com wrote: The resize code as written originally did the simplest possible thing. It converts and copies the whole file so that it doesn’t have to figure out how to sync backing files etc. This could definitely be improved, especially now that there is code in _create_images_and_backing that can ensure that backing files are downloaded/created if they are not there. Additionally the resize code should be using something other than ssh/rsync. I’m a fan of using glance to store the file during transfer, but others have suggested using the live migrate code or libvirt to transfer the disks. I'd like to suggest an additional improvement - if the resize is only a CPU/Memory resize, then if the host can handle it the entire disk flattening/conversion/migration should be skipped and the resize of the CPU/Memory spec should be done in-place on the host. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
But right now, we trigged resize by flavor changed. Do you mean we can split the resize by cpu, by memory, or by disk? 在 2014-07-25 03:25:46，Jesse Pretorius jesse.pretor...@gmail.com 写道： On 24 July 2014 20:38, Vishvananda Ishaya vishvana...@gmail.com wrote: The resize code as written originally did the simplest possible thing. It converts and copies the whole file so that it doesn’t have to figure out how to sync backing files etc. This could definitely be improved, especially now that there is code in _create_images_and_backing that can ensure that backing files are downloaded/created if they are not there. Additionally the resize code should be using something other than ssh/rsync. I’m a fan of using glance to store the file during transfer, but others have suggested using the live migrate code or libvirt to transfer the disks. I'd like to suggest an additional improvement - if the resize is only a CPU/Memory resize, then if the host can handle it the entire disk flattening/conversion/migration should be skipped and the resize of the CPU/Memory spec should be done in-place on the host. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
On 25 July 2014 09:50, Li Tianqing jaze...@163.com wrote: But right now, we trigged resize by flavor changed. Do you mean we can split the resize by cpu, by memory, or by disk? No, what I mean is that if the source and target flavor have the same root and ethereal disk size, then check if the current host can handle the resize operation on itself and do the resize without involving any of the disk operations. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova]resize
In resize, we convert the disk and drop peel backing file, should we judge whether we are in shared_storage? If we are in shared storage, for example, nfs, then we can use the image in _base to be the backing file. And the time cost to resize will be faster. The processing in line 5132 https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py Thanks___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
whether we already use like that ? https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5156 From: fdsafdsafd [mailto:jaze...@163.com] Sent: Thursday, July 24, 2014 4:30 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova]resize In resize, we convert the disk and drop peel backing file, should we judge whether we are in shared_storage? If we are in shared storage, for example, nfs, then we can use the image in _base to be the backing file. And the time cost to resize will be faster. The processing in line 5132 https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py Thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
No.
before L5156, we convert it from qcow2 to qcow2, in which it strips backing
file.
I think here, we should wirte like this:
if info['type'] == 'qcow2' and info['backing_file']:
if shared_storage:
utils.execute('cp', from_path, img_path)
else:
tmp_path = from_path + _rbase
# merge backing file
utils.execute('qemu-img', 'convert', '-f', 'qcow2',
'-O', 'qcow2', from_path, tmp_path)
libvirt_utils.copy_image(tmp_path, img_path, host=dest)
utils.execute('rm', '-f', tmp_path)
else: # raw or qcow2 with no backing file
libvirt_utils.copy_image(from_path, img_path, host=dest)
At 2014-07-24 05:02:39, Tian, Shuangtai shuangtai.t...@intel.com wrote:
!--
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
_font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Calibri,sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri,sans-serif;}
_page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--
whether we already use like that ?
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5156
From: fdsafdsafd [mailto:jaze...@163.com]
Sent: Thursday, July 24, 2014 4:30 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova]resize
In resize, we convert the disk and drop peel backing file, should we judge
whether we are in shared_storage? If we are in shared storage, for example,
nfs, then we can use the image in _base to be the backing file. And the time
cost to resize will be faster.
The processing in line 5132
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py
Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
The resize code as written originally did the simplest possible thing. It
converts and copies the whole file so that it doesn’t have to figure out how
to sync backing files etc. This could definitely be improved, especially now
that
there is code in _create_images_and_backing that can ensure that backing files
are
downloaded/created if they are not there.
Additionally the resize code should be using something other than ssh/rsync. I’m
a fan of using glance to store the file during transfer, but others have
suggested
using the live migrate code or libvirt to transfer the disks.
Vish
On Jul 24, 2014, at 2:26 AM, fdsafdsafd jaze...@163.com wrote:
No.
before L5156, we convert it from qcow2 to qcow2, in which it strips backing
file.
I think here, we should wirte like this:
if info['type'] == 'qcow2' and info['backing_file']:
if shared_storage:
utils.execute('cp', from_path, img_path)
else:
tmp_path = from_path + _rbase
# merge backing file
utils.execute('qemu-img', 'convert', '-f', 'qcow2',
'-O', 'qcow2', from_path, tmp_path)
libvirt_utils.copy_image(tmp_path, img_path, host=dest)
utils.execute('rm', '-f', tmp_path)
else: # raw or qcow2 with no backing file
libvirt_utils.copy_image(from_path, img_path, host=dest)
At 2014-07-24 05:02:39, Tian, Shuangtai shuangtai.t...@intel.com wrote:
!--
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
_font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Calibri,sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri,sans-serif;}
_page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--
whether we already use like that ?
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5156
From: fdsafdsafd [mailto:jaze...@163.com]
Sent: Thursday, July 24, 2014 4:30 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova]resize
In resize, we convert the disk and drop peel backing file, should we judge
whether we are in shared_storage? If we are in shared storage, for example,
nfs, then we can use the image in _base to be the backing file. And the time
cost to resize will be faster.
The processing in line 5132
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py
Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]resize
Agree with you now
-Original Message-
From: fdsafdsafd [mailto:jaze...@163.com]
Sent: Thursday, July 24, 2014 5:26 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova]resize
No.
before L5156, we convert it from qcow2 to qcow2, in which it strips backing
file.
I think here, we should wirte like this:
if info['type'] == 'qcow2' and info['backing_file']:
if shared_storage:
utils.execute('cp', from_path, img_path)
else:
tmp_path = from_path + _rbase
# merge backing file
utils.execute('qemu-img', 'convert', '-f', 'qcow2',
'-O', 'qcow2', from_path, tmp_path)
libvirt_utils.copy_image(tmp_path, img_path, host=dest)
utils.execute('rm', '-f', tmp_path)
else: # raw or qcow2 with no backing file
libvirt_utils.copy_image(from_path, img_path, host=dest)
At 2014-07-24 05:02:39, Tian, Shuangtai shuangtai.t...@intel.com wrote:
!--
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
_font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
_font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
_font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:SimSun;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Calibri,sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri,sans-serif;}
_page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--
whether we already use like that ?
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L5156
From: fdsafdsafd [mailto:jaze...@163.com]
Sent: Thursday, July 24, 2014 4:30 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova]resize
In resize, we convert the disk and drop peel backing file, should we judge
whether we are in shared_storage? If we are in shared storage, for example,
nfs, then we can use the image in _base to be the backing file. And the time
cost to resize will be faster.
The processing in line 5132
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py
Thanks
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
