So! Perhaps you’ve read my article on nova-agent , the common cause of this issue? If you haven’t you should since it covers out well the importance of nova-agent. <\/p>\n
However, nova-agent itself also comes unstuck if the machine nova-agent is installed on is missing the xe-linux-distribution service, this service is provided by the package xe-guest-utilities and can be installed by yourselves, in the case that installing\/ ensuring nova-agent starts on boot does not fix your issues.<\/p>\n
Specifically if your nova-agent log provides you this message, you know you need to install the xe-guest-utilities. Simplies!<\/p>\n
\r\n# cat \/var\/log\/nova-agent.log\r\n\r\n2016-10-06 18:58:14,696 [ERROR] [EXC] Traceback (most recent call last):\r\n2016-10-06 18:58:14,697 [ERROR] [EXC] File \"\/usr\/share\/nova-agent\/nova-agent.py\", line 40, in\r\n2016-10-06 18:58:14,697 [ERROR] [EXC] xs = plugins.XSComm()\r\n2016-10-06 18:58:14,697 [ERROR] [EXC] File \"\/usr\/share\/nova-agent\/1.39.0\/plugins\/xscomm.py\", line 43, in __init__\r\n2016-10-06 18:58:14,697 [ERROR] [EXC] self.xs_handle = pyxenstore.Handle()\r\n2016-10-06 18:58:14,700 [ERROR] [EXC] PyXenStoreError: Couldn't open connection to the xenstore: No such file or directory\r\n2016-10-06 18:58:14,701 [ERROR] failed to parse config file '\/usr\/share\/nova-agent\/nova-agent.py'\r\n<\/pre>\n Solution <\/h2>\n
\r\n# Redhat and CentOS systems\r\nyum install xe-guest-utilities\r\n\r\n# Debian, Ubuntu and other apt based systems\r\napt-get install xe-guest-utilities\r\n<\/pre>\nI hope that this is of some assistance, here is some more background information. <\/p>\n
More details about nova-agent and xe-guest-utilities in Xen <\/h2>\n
Provided that you have definitely enabled nova-agent, and ensured that it is running (after restarting the original server), with ps auxfwww | grep nova-agent <\/p>\n
then, you should be good to re-image the original server, and then rebuild out the second. <\/p>\n
The reason why your server doesn’t appear to be coming up in the new build is for some reason, nova-agent service got disabled on boot-time, and as a result, the nova-agent service responsible for swapping out the network configuration of your cloud-server wasn’t started up when the server was built, and the automatic ip configuration change didn’t occur. This explains well the behaviour you’ve been seeing, and after looking in the backend the error code seems to confirm that the issue was that the nova-agent wasn’t running. <\/p>\n
Provided that you’ve definitely installed nova-agent and confirmed it is running, as well as made sure it starts at boot time, as in the article I wrote, you should be good.<\/p>\n
I hope that this explanation and clarification meets you well.<\/p>\n
I can see that you’ve recently posted an additional issue that has been experienced with xe-linux-distribution (the cause of the PyXenStoreError). This secondary cause of the issue can be fixed by ensuring xe-linux-distribution is installed;<\/p>\n
apt-get update;
\napt-get install xe-guest-utilities<\/p>\nThis should install the xen guest tools as required by nova-agent. This is required by the nova-agent in order for the networking data to be retrieved by nova-agent, whereas nova-agent itself applies the change, but these services both need to be running and installed for this to work properly!<\/p>\n
I really hope that this is of some assistance ,of course if you have additional questions, comments or concerns please don’t hesitate to write back, and we can escalate this issue further for you. These instructions should fix your issues though! I hope this helps &<\/p>\n","protected":false},"excerpt":{"rendered":"
So! Perhaps you’ve read my article on nova-agent , the common cause of this issue? If you haven’t you should since it covers out well the importance of nova-agent. However, nova-agent itself also comes unstuck if the machine nova-agent is … Continue reading