Re: [openstack-dev] [nova]resize
On 25 July 2014 09:50, Li Tianqing 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
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" 写道： On 24 July 2014 20:38, Vishvananda Ishaya 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 24 July 2014 20:38, Vishvananda Ishaya 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
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" 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:
>
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" wrote:
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
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 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" wrote:
>
>
>
>
>
>
>
>
>
>
>
> 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
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" wrote:
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
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] [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
