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
