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

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'}

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

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.