EDITED by Lucio: Make sure to register all files (image + kernel + ramdisk). That was our first issue... we were not using the ramdisk and the machine was not starting because of that... after lots of coffee and mate we figured out why the machine was not starting...
The next step was to create an instance, using the euca-run-instances command. It goes without saying that this failed. Our instances remained forever trapped in the pending state, never to be started. The node controller log file was of no real use, providing an error message that led us to no solutions despite extensive googling. Our first instinct was to attempt to start the image manually on our node. We created the necessary Xen configuration file and successfully started the virtual machine, proving that the image itself was not the issue. After much poking and prodding, we determined that we were only specifying the kernel and file system images, but also had a ramdisk image available that we were not making use of. We added this to Walrus and included it in our call to euca-run-instances, and met with success. Well, sort of.
euca-run-instances -k mykey --kernel eki-907A1380 --ramdisk eri-AE9113E8 emi-3F0A1253
Our virtual machine had no IP address, and thus no way for us to connect to it. While it was comforting to know that it was there, happily doing nothing, we needed to be able to actually talk to it. We experimented with the different network configuration modes of Eucalyptus, that is, SYSTEM, STATIC, and MANAGED, with little success. We then disconnected our switch from the network and installed a DHCP server on homer. The Eucalyptus network configuration mode was set to SYSTEM, which means that Eucalyptus simply assigns a random MAC address to each VM and lets DHCP handle the rest. With this setup, we were successfully able to start a VM with an IP address and connect to it via SSH.
The problem will be converting this into something usable. At the moment, our cloud is in complete isolation from the rest of the world. We have two options: 1) we reconnect our cloud to the network and secure ourselves a range of IP addresses that we have control over and can assign via our DHCP server, or 2) we keep the cloud on its own network and add a second NIC card to our cloud controller (homer) for external access. All access to the cloud would then be routed through this machine. While option #1 seems like the ideal solution, option #2 is far more feasible at the moment, and hence this will be our route for the time being.
Until next time,
Mike
The next step was to create an instance, using the euca-run-instances command. It goes without saying that this failed. Our instances remained forever trapped in the pending state, never to be started. The node controller log file was of no real use, providing an error message that led us to no solutions despite extensive googling. Our first instinct was to attempt to start the image manually on our node. We created the necessary Xen configuration file and successfully started the virtual machine, proving that the image itself was not the issue. After much poking and prodding, we determined that we were only specifying the kernel and file system images, but also had a ramdisk image available that we were not making use of. We added this to Walrus and included it in our call to euca-run-instances, and met with success. Well, sort of.
euca-run-instances -k mykey --kernel eki-907A1380 --ramdisk eri-AE9113E8 emi-3F0A1253
Our virtual machine had no IP address, and thus no way for us to connect to it. While it was comforting to know that it was there, happily doing nothing, we needed to be able to actually talk to it. We experimented with the different network configuration modes of Eucalyptus, that is, SYSTEM, STATIC, and MANAGED, with little success. We then disconnected our switch from the network and installed a DHCP server on homer. The Eucalyptus network configuration mode was set to SYSTEM, which means that Eucalyptus simply assigns a random MAC address to each VM and lets DHCP handle the rest. With this setup, we were successfully able to start a VM with an IP address and connect to it via SSH.
The problem will be converting this into something usable. At the moment, our cloud is in complete isolation from the rest of the world. We have two options: 1) we reconnect our cloud to the network and secure ourselves a range of IP addresses that we have control over and can assign via our DHCP server, or 2) we keep the cloud on its own network and add a second NIC card to our cloud controller (homer) for external access. All access to the cloud would then be routed through this machine. While option #1 seems like the ideal solution, option #2 is far more feasible at the moment, and hence this will be our route for the time being.
Until next time,
Mike
Posts
No comments:
Post a Comment