Hi Darrin, thanks for your response. the topic in regarding isn't stirctly related to ssh. It's about "adding a KVM-Host manually"
https://github.com/apache/cloudstack/issues/3067#issuecomment-444076352 I "stumbled" over the solution for this bye searching. In the official docs there was no hint in the installationguide for KVM Hosts. > - connections couldn't be established as the agent.conf had no IP-addresses > for the management-server > This will be remedied when the agent is added from the management server > successfully. > Which is quite logical - at least as long as you are able to add the host in a fresh setting right out of the box - in accordance with the installation guide. Until now that was not the case for me. Same goes with your other points: If the setup is correct everything should work fine. As descriped in various guides and docs, while installing cloudstack management server packages as well as the cloud-stack agent, all needed packages for supported environments and installations should be done with the actual installation (besides network and hostname) - at least that is my information reading through github and some of the guides Example: https://github.com/apache/cloudstack/issues/4754#issuecomment-793542173 But some things are there during installtion - others won't. Remote-Access via ssh for root-users on a host as an example. There is no indication in the docs at the moment, that there is a need to change some settings for this - ev en on an officially supported OS for the host. So I often end in looking through various logs and files, which configurtation actually is done while installing the cloudstack-agent for example. i contributed to the setup guides already some of the things. But contributing while not exactly knowing the process can be problematic... As the processes how and what is happening aren't in the docs at the moment. I can only try to read through the scripts on github. But as I am not very keen with programming at all, there are some gaps for me. Would love to see some kind of activity-diagramms or configurtation charts. Nevertheless let me once again thank you for your time and patience, with regards, chris Am Mi., 14. Apr. 2021 um 09:54 Uhr schrieb Darrin Hüsselmann <[email protected]>: > > Hi Chris, > > Please elaborate on: > - ssh keys not working because of mangement server settings > I'm not sure what you mean here. > > - connections couldn't be established as the agent.conf had no IP-addresses > for the management-server > This will be remedied when the agent is added from the management server > successfully. > > If your host is set up correctly the management server will be able to talk > to the agent over the network interface cloudbr0, qemu-kvm would be set up > correctly and the agent would be able to read and write to primary and > secondary storages. > > Before you can create an instance : > > Your hosts must be up > Primary and secondary storages must be added > Your zone must be enabled. > CPVM and SSVM agents must be up and connected > The default template should be done downloading > > > After the zone is enabled with hosts up and primary and secondary storage > added, Cloudstack will try to start the system VMs. The system VMs are > created from the systemVM template, which should have already been uploaded > manually to secondary storage. Once the SSVM is up and connected, it will > start to download the built-in template. When this is done you will be able > to start an instance from the built-in template. > > If there are some missing steps in the setup guide feel free to make an > addition to the docs by raising a PR on > https://github.com/apache/cloudstack-documentation or logging an issue. > > Cheers > Darrin > > > > > > [email protected] > www.shapeblue.com > @shapeblue > > > > > ________________________________ > From: [email protected] <[email protected]> > Sent: Friday, April 9, 2021 8:56 PM > To: [email protected] <[email protected]> > Subject: Re: Services of management server listening on IPv6 Ports > > Hi Darin, > > well from a "technical" point of view, i currently have problems > getting the ssvm running. I have to admit that i need to take a closer > look into the logs myself to see what is happening. First messages i > read stated some problems with primary / secondary storage and the > given uuids. Might be a problem as i joyned the compute host in an > unusal(?) or not described way... > Which leads to my next problem: > Understanding the process of joining hosts. > Described in the documentation are more or less always the same way. > Log in to the management server gui - add host - give the requiered > data - and then the host will join (given the agent on the host is > installed properly). However, in non of my installation-trials this > worked out of the box (even if ubuntu 20.04 is expicit named in the > compability matrix). > Problems have been (using ubuntu server 20.04): > - ssh keys not working because of mangement server settings > - usage of older SSH algorithms... > - connections couldn't be established as the agent.conf had no > IP-addresses for the management-server (which is from my understanding > "normal" - the host can't know anything about the management server > till the connection from the management server is initialized). > however the agent is all the time lookining for an management server. > - missing uuid entrys.... > - missing rights for users (as root isn't allowed connect via ssh out > of the box) > Nothing of this is part of the latest integration guide / mentioned in > the docs - beside the SSH algorithms in the release notes for 4.15 > (shame on me for reading them to late). > > Don't get me wrong i am not blameing it on cloudstack at all- but > without all the background information it is hard to solve occuring > problems. > > I really like many of the appoaches CloudStack is useing and > following. But from an "installation" point of view the installation > of OpenStack was more successfull and more "straight-forward" then the > installation of CloudStack. > > with regards > Chris > > Am Fr., 9. Apr. 2021 um 08:35 Uhr schrieb Darrin Hüsselmann > <[email protected]>: > > > > Great, > > > > What other issues are you facing? > > > > Regards > > Darrin > > > > [email protected] > > www.shapeblue.com > > @shapeblue > > > > > > > > > > ________________________________ > > From: [email protected] <[email protected]> > > Sent: Thursday, April 8, 2021 9:08 PM > > To: Darrin Hüsselmann <[email protected]> > > Subject: Re: Services of management server listening on IPv6 Ports > > > > Hi Darrin, > > > > thanks for the information provided! Was interesting to read this. > > > > even if i am still faceing some other issues at the moment. > > > > Am Do., 8. Apr. 2021 um 09:24 Uhr schrieb Darrin Hüsselmann > > <[email protected]>: > > > > > > Hi Chris, > > > > > > I think this link might shed some light on your findings. > > > > > > https://unix.stackexchange.com/questions/573456/why-does-lsof-indicate-my-ipv4-socket-is-ipv6 > > > > > > Cheers > > > Darrin > > > > > > [email protected] > > > www.shapeblue.com > > > @shapeblue > > > > > > > > > > > > > > > ________________________________ > > > From: [email protected] <[email protected]> > > > Sent: Thursday, March 25, 2021 12:26 PM > > > To: [email protected] <[email protected]> > > > Subject: Services of management server listening on IPv6 Ports > > > > > > Hi everyone, > > > > > > I was setting up an test-environment with an IPv4 network beneath. > > > OS of the server is Ubuntu 20.04.02-live-server. > > > > > > After performing the installation like descriped in the installation > > > guide, the server seems fine. > > > One thing i noticed is, that the sockets for the services of > > > cloudstack / listening ports are all IPv6 based: > > > > > > root@management:~# lsof -i -P -n | grep cloud | grep LISTEN > > > java 1184 cloud 12u IPv6 48210 0t0 TCP *:35947 > > > (LISTEN) > > > java 1184 cloud 21u IPv6 50162 0t0 TCP *:9090 > > > (LISTEN) > > > java 1184 cloud 22u IPv6 48825 0t0 TCP *:35627 > > > (LISTEN) > > > java 1184 cloud 26u IPv6 51204 0t0 TCP *:8250 > > > (LISTEN) > > > java 1184 cloud 30u IPv6 52307 0t0 TCP *:8080 > > > (LISTEN) > > > > > > Shouldn't these services also listening on IPv4 addresses of the > > > management interface? > > > > > > Thanks in advance! > > > Chris
