try setting secstorage.allowed.internal.sites in Global Settings in the UI to include that ip or subnet 10.19.40.0/24
On May 19, 2014, at 4:44 PM, Steve Cleveland <[email protected]> wrote: > > On 05/19/2014 04:30 PM, Carlos Reátegui wrote: >> Not sure if this will help but try disabling iptables on the XS host. > > The 10.19.40.81 address is the MS. I have tried disabling iptables on both > MS and XS but no change. > > - Steve > > >> >> >> On May 19, 2014, at 3:51 PM, Steve Cleveland <[email protected]> >> wrote: >> >>> I'm running into a few problems setting up cloudstack for the first time. >>> Most I've resolved, but I wanted to share. I'm using CentOS 6.5 and >>> XenServer 6.2. Both have the latest updates installed. And I'm using an >>> external MariaDB 5.5.35 server and an external NFS server (both primary and >>> secondary storage). I'm following these instructions: >>> >>> http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/installation.html >>> >>> 1. The RPM package repository shows setting up 4.2. Substituting 4.3 works >>> fine. >>> >>> 2. The section on MySQL running on the MS says to run >>> cloudstack-setup-management on step 9. Using an external MySQL section >>> does not include this step, but causes errors if I manually try to start >>> the cloudstack-managment service. I assume that's just a documentation >>> problem and that I'm supposed to run cloudstack-setup-management. >>> >>> 3. After running 'cloudstack-setup-management' it starts the service. But >>> the web interface never comes up (I get a service unavailable error). The >>> management-server.log file has this error: >>> >>> 2014-05-19 13:19:42,120 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) >>> Unable to execute upgrade script: >>> /usr/share/cloudstack-management/setup/db/schema-421to430.sql >>> java.sql.SQLException: You can't specify target table 'configuration' for >>> update in FROM clause >>> >>> I've duplicated this multiple times. It appears that the >>> cloudstack-setup-databases script configures an older database layout and >>> then has to run this script when it first starts. But there are two lines >>> that are invalid, at least to MariaDB. >>> >>> UPDATE `cloud`.`configuration` SET value = CONCAT("*.",(SELECT >>> `temptable`.`value` FROM (SELECT * FROM `cloud`.`configuration` WHERE >>> `name`="consoleproxy.url.domain") AS `temptable` WHERE >>> `temptable`.`name`="consoleproxy.url.domain")) WHERE >>> `name`="consoleproxy.url.domain"; >>> UPDATE `cloud`.`configuration` SET `value` = CONCAT("*.",(SELECT >>> `temptable`.`value` FROM (SELECT * FROM `cloud`.`configuration` WHERE >>> `name`="secstorage.ssl.cert.domain") AS `temptable` WHERE >>> `temptable`.`name`="secstorage.ssl.cert.domain")) WHERE >>> `name`="secstorage.ssl.cert.domain"; >>> >>> That table is empty on a new install anyway (which may be the reason for >>> the error), so I commented them out. Since it failed part way through, it >>> generates more errors. So I've had to delete the databases and rerun >>> cloudstack-setup-databases and restart the service. >>> >>> 4. I download vhd-util to >>> /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver on the MS >>> before adding the XenServer, but it doesn't get copied to >>> /opt/xensource/bin. I manually copy it and is then able to create the >>> system VMs. >>> >>> 5. After I setup the zone, I finally get the s- and v- VMs running. But I'm >>> not getting the CentOS built-in template. It just says "Ready: No". If I >>> login to the SSVM and look at /var/log/cloud.log, I see: >>> >>> 2014-05-19 22:29:59,143 INFO [utils.nio.NioClient] (Agent-Selector:null) >>> Connecting to 10.19.40.81:8250 >>> 2014-05-19 22:29:59,147 ERROR [utils.nio.NioConnection] >>> (Agent-Selector:null) Unable to initialize the threads. >>> java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection >>> closed with -1 on reading size. >>> at com.cloud.utils.nio.NioClient.init(NioClient.java:84) >>> at com.cloud.utils.nio.NioConnection.run(NioConnection.java:108) >>> at java.lang.Thread.run(Thread.java:679) >>> >>> It happens over and over about every five seconds. I'm guessing this is >>> the source of my problem. If I run >>> /usr/local/cloud/systemvm/ssvm-check.sh, it reports everything is Good. I >>> haven't setup SSL in any fashion as it's an early PoC. >>> >>> The Systems VM page shows both system VMs as up. But the >>> management-server.log file prints this every 30 seconds: >>> >>> 2014-05-19 15:41:38,556 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] >>> (secstorage-1:ctx-ed6e40a6) Zone 1 is ready to launch secondary storage VM >>> >>> Any help with this last issue is greatly appreciated. Again, this a >>> brand-new, unmodified installation. >>> >>> Thanks, >>> - Steve >>
