← Back to team overview

openstack team mailing list archive

Re: Server resize API in OpenStack ESSEX

 

On a general note a user would expect that the delay during migration will be higher than the delay while resizing. Also, in this case it appears that the resizing functionality performs migration rather scaling up or down the VM. Can I get to know the resizing options using which the instance can be retained on the same compute node? Can I also get to know whether the scheduler checks for the new hardware requirements on the original compute node before it migrates to the new compute node?
From: openstack-bounces+narayana=uni-mainz.de@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+narayana=uni-mainz.de@xxxxxxxxxxxxxxxxxxx] On Behalf Of Narayanan, Krishnaprasad
Sent: Montag, 10. Dezember 2012 22:54
To: Vishvananda Ishaya
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Server resize API in OpenStack ESSEX

As you had mentioned I went through the logs and I could see an error message with the "Host Key Verification Failed with exit code 255 on Command: ssh IP address mkdir -p /var/lib/nova/instances/instance-000000155". If I get it correctly, this means that the key on the compute nodes that was cached earlier has been changed. Can I get to know is this correct and how to get rid of this problem?
From: Vishvananda Ishaya [mailto:vishvananda@xxxxxxxxx]
Sent: Montag, 10. Dezember 2012 20:23
To: Narayanan, Krishnaprasad
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Server resize API in OpenStack ESSEX

The code scps the backing file for the instance to the new node via something along the lines of:
scp /var/lib/nova/instances/instance-xxx/disk <hostname>:/var/lib/nova/instances/instance-xxx/disk
So the hostname has to properly resolve to the ip of the target machine. You should see messages in the compute log about it trying to do this. The error message there might give you a better idea of what failed.

Yes resize will go through the scheduler and usually find a new compute node. The conf option does not force it to use the same host, so it is mostly just there for testing.

Vish

On Dec 10, 2012, at 11:12 AM, "Narayanan, Krishnaprasad" <narayana@xxxxxxxxxxxx<mailto:narayana@xxxxxxxxxxxx>> wrote:

Hi Vish,


Thanks for the quick reply. I have passwordless ssh between the compute hosts but could you explain me the first option. When I resize, will the instance redeploy on a different compute node?

Do I need to specify this flag allow_resize_to_same_host=true in nova.conf of the compute node?



Regards,

Krishnaprasad
From: Vishvananda Ishaya [mailto:vishvananda@xxxxxxxxx<http://gmail.com>]
Sent: Montag, 10. Dezember 2012 20:03
To: Narayanan, Krishnaprasad
Cc: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Server resize API in OpenStack ESSEX

2 requirements:

1) hostname for compute hosts resolve properly
2) passwordless ssh works between compute hosts.

Vish

On Dec 10, 2012, at 10:37 AM, "Narayanan, Krishnaprasad" <narayana@xxxxxxxxxxxx<mailto:narayana@xxxxxxxxxxxx>> wrote:


Hallo All,

I am trying to use the Nova API (POST call) for changing the flavor information (to resize) from m1.tiny to m1.medium. Even though the API is successful (202 Status code), on the Horizon GUI I could see that the Status is Error and the task state is Resize Prep. I am passing the Auth Token along with the Body information in the form of json as inputs to the API. I have referred this URI<http://docs.openstack.org/api/openstack-compute/programmer/content/resizing-servers.html> for passing the body information.

I am using OpenStack ESSEX and can I get to know is there any configurations that I need to do in order to get this working?

Thanks
Krishnaprasad
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


Follow ups

References