OpenStack Compute (nova)

Is it possible to increase the timeout value while looking for agent plugin on XenServer?

Asked by Giuseppe Civitella

Hi all,
I'm trying to setup Administrator password on a windows image.
The image is deployed on XenServer so I'm relying on xentools and the guest agent to set the password.
Since at the first boot the OS executes a sysprep, the agent takes a long time to start and the nova-compute's call which ask for plugin version timeouts.
It there a way to increase the timeout value or to work around this problem?

thanks a lot

Question information

Language:
English Edit question
Status:
Solved
For:
OpenStack Compute (nova) Edit question
Assignee:
No assignee Edit question
Solved by:
Giuseppe Civitella
Solved:
Last query:
Last reply:
Revision history for this message
Giuseppe Civitella (gcivitella) said : 		#1

In nova/virt/xenapi/vmops.py
at row 55 I see there is a timeout defined:
flags.DEFINE_integer('agent_version_timeout', 300,

I did try to increase it but I receive anyway the following error:
012-01-17 18:36:32,663 ERROR nova.virt.xenapi.vmops [-] TIMEOUT: The call to password timed out. VM id=42f3bf42-7619-46bd-8c8b-e27c67a3fe6e; args={'enc_pass': 'wWAGii5J9Rfu5IfUpjLG/w==', 'path': '', 'dom_id': '47', 'id': '8b8473d5-c008-4b18-a2e8-28d9aaa55e76'}
2012-01-17 18:36:32,663 ERROR nova.virt.xenapi.vmops [-] Failed to update password: {'message': 'TIMEOUT: No response from agent within 30 seconds.', 'returncode': 'timeout'}

Revision history for this message
Johannes Erdfelt (johannes.erdfelt) said : 		#2

The error you pasted is the password request failing. This occurs after the agent version is requested. agent_version_timeout only affects the agent version query and not the subsequent setting of the password.

There should be entries in the log before the snippet you included about the agent version. Can you paste that as well?

Revision history for this message
Giuseppe Civitella (gcivitella) said : 		#3

These are some relevant entries about a windows deploy:
http://paste.openstack.org/show/4391/

On my nova-compute log, at service startup, I can see:
2012-01-18 09:32:08,278 DEBUG nova [-] agent_version_timeout : 1800 from (pid=6813)

Thanks

Revision history for this message
Giuseppe Civitella (gcivitella) said : 		#4

The problem could be the windows agent which exits with code 0 and outputs nothing when receives an agent version request.
It lets the spawing process on nova-compute go to the set admin password phase without a fully working agent.

Revision history for this message
Giuseppe Civitella (gcivitella) said : 		#5

Increasing the agent_version_timeout as reported before solved my problem.
The password problem was agent related.
Anyway it coud be useful to set the agent_version_timeout in the nova.conf