Finally found how to fix-it persistent-ly: *1. Upgrade tomcat version*
Following the clue from that thread: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 - wget https://archive.apache.org/dist/tomcat/tomcat-6/v6.0.53/bin/ apache-tomcat-6.0.53.tar.gz - tar --directory /opt -xzf apache-tomcat-6.0.53.tar.gz - mv /usr/share/tomcat6/lib /usr/share/tomcat6/lib.old - mv /usr/share/tomcat6/bin /usr/share/tomcat6/bin.old - ln -s /opt/apache-tomcat-6.0.53/lib /usr/share/tomcat6/lib - ln -s /opt/apache-tomcat-6.0.53/bin /usr/share/tomcat6/bin - service cloudstack-management restart *2. Fix systemvm.iso* Fix the ISO so it creates the upload directory when a new SSVM is created: cd /usr/share/cloudstack-common/vms/ mkdir tmp mount -o loop systemvm.iso tmp cp -rp tmp /tmp/cloud umount tmp rmdir tmp cd /tmp/cloud/ mkdir aux cd aux tar xzvf ../cloud-scripts.tgz mkdir var/www/html/upload rm -f ../cloud-scripts.tgz tar czvf ../cloud-scripts.tgz * cd .. rm -rf aux cd .. mkisofs -o new_systemvm.iso -J -R cloud/* rm -rf cloud/ mv /usr/share/cloudstack-common/vms/systemvm.iso /usr/share/cloudstack-common/vms/systemvm.iso.orig mv new_systemvm.iso /usr/share/cloudstack-common/vms/systemvm.iso Destroy the SSVM and wait for the new to be created. SSH it and check that /var/www/html/upload dir is created. Check also that you can upload from local. Regards. Atentamente, Sebastián Gómez On Sat, May 27, 2017 at 8:33 AM, Sebastian Gomez <tioc...@gmail.com> wrote: > Hello all! > > (I work with Marc) > > Thanks Ilya: > > About the Template upload from local--> > > - I installed the lastest tomcat 6 stable release, but the problem was not > solved. > - I fixed the problem creating the /var/www/html/public dir at the SSVM > and it worked. > > But this change will be lost when the SSVM is destroyed and another new is > created. > Is an issue on the systemvm? > > I can't believe that we are the only one that have this issue, so, I think > that during our upgrade from 4.5 something has been lost. > > > Any recomendations? > > > Thanks again. > > > > > > > > Atentamente, > Sebastián Gómez > > On Fri, May 26, 2017 at 8:38 PM, ilya <ilya.mailing.li...@gmail.com> > wrote: > >> Please see comments in-line >> >> On 5/25/17 2:14 AM, Marc Poll Garcia wrote: >> > Hi all, >> > >> > we have just upgraded our cloud environment based on Cloudstack 4.5.2 to >> > 4.9.2 and we're expriencing some issues after this. >> > >> > Our setup is the following one: >> > >> > - 1 x cloudstack managment server >> > - 1 x bbdd server cloudstack database on it >> > - 2 x Vmware Hipervisors (hosts) >> > >> > I'm performing a list of tests: >> > >> > *- Sometimes, and randomly console from instances does not load.* >> > *- Not possible to upload template from local.* >> > >> > We see the following on log: >> > >> > 2017-05-25 09:00:31,665 ERROR [c.c.s.ImageStoreUploadMonitorImpl] >> > (Upload-Monitor-1:ctx-0b3bf6e9) (logid:e9c82a0f) *Template >> > b87459ac-8fbe-4b34-ae25-21235c3fcd1d failed to upload due to operation >> > timed out* >> We need more info on this, try >> >> grep ctx-0b3bf6e9 -A5 -B5 cloudstack-management.log >> >> > 2017-05-25 09:02:18,265 ERROR [c.c.c.ClusterServiceServletContainer] >> > (Thread-11:null) (logid:) *Unexpected exception * >> Is there more for this? >> >> >> > 2017-05-25 09:03:35,940 ERROR [c.c.c.ClusterManagerImpl] (main:null) >> > (logid:) *Unable to ping management server at 192.168.100.2:9090 >> > <http://192.168.100.2:9090> due to ConnectException* >> >> Safe to ignore. >> >> >> Here is a suggestion, stop your MGMT server, then empty the log file >> (make a backup of it prior if needed) >> cat /dev/null > cloudstack-management.log >> start cloudstack management, give it few minutes to load - run >> operations that fail - post the management logs to pastebin or google >> drive.. >> >> >> Also - what version of tomcat are you running? >> >> CentOS 6 and 7 come with an older version of tomcat that has an issue >> with socket timeouts, you can read it here: >> https://issues.apache.org/jira/browse/CLOUDSTACK-7907 >> >> >> as to console not working - make sure console proxy VM and cloudstack MS >> can access the ESXi and vCenter or proper ports, like 443, 901 and >> higher VNC ports. >> >> To find out why it does not work sometimes, login to console proxy VM, >> and via netstart check for any connections in TIME_WAIT state. That will >> tell you if there are network issues. >> >> Regards >> ilya >> >> >> >> > >> > Why is it happening? >> > It does not happen on our old 4.5.2 version. >> > >> > Is there any way to fix it? changing any global parameter or permissions >> > issue? >> > >> > We need a clue with that because if affecting to our production >> environment. >> > >> > Thanks in advance. >> > >> > Kind regards. >> > >> > >
