There's 3 minimum requirements to start a system vm: 1. The zone is enabled 2. There is primary storage ready that matches the type of the system vm offering (e.g., if only local is available, then system vm disk offering also needs to be local) 3. The system vm templates are DOWNLOADED 3. There are enough hosts in the 'UP' state select * from (select h.data_center_id, h.type, count(*) as count from host as h INNER JOIN mshost as m ON h.mgmt_server_id=m.msid where h.status='Up' and h.type='SecondaryStorage' and m.last_update > ? group by h.data_center_id, h.type UNION ALL select h.data_center_id, h.type, count(*) as count from host as h INNER JOIN mshost as m ON h.mgmt_server_id=m.msid where h.status='Up' and h.type='Routing' and m.last_update > ? group by h.data_center_id, h.type) as t ORDER by t.data_center_id, t.type;
The '?' is to be replaced by a date equivalent to now() in GMT - 150 secs On 12/3/12 6:58 PM, "Chiradeep Vittal" <chiradeep.vit...@citrix.com> wrote: >So what is the result of the below SQL query if you run it by hand? >Use data_center.allocation_state = 'Enabled' > > >On 11/29/12 9:54 AM, "Jeff Reed" <jeffr...@jeffreed.net> wrote: > >>Hey folks, >> >>I'm having a problem after upgrading from cloudstack 3.0.2 to 4.0. I >>followed the instructions here: >>http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0 >>- >>incubating/html/Release_Notes/upgrade-instructions.html#upgrade-from-3.0. >>2 >>-to-4.0 >> >>I've upgraded the agent machines from CentOS 6.2 to CentOS 6.3 and all >>packages are current, and am running KVM as the hypervisor. The >>management server isn't running as an agent. There are two machines >>running as agents. I have a mishmash of hardware, but all CPUs are AMD >>Phenoms. >> >>I used the convenience packages from >>http://cloudstack.apt-get.eu/rhel/4.0 to do the upgrade. >> >>I have everything running, except for the system vms. Neither the >>console proxy nor the secondary storage VMs are running, or even seem to >>try to start. I can start VMs from my templates, and everything seems to >>work fine, but (obviously) the console proxy doesn't work, and machines >>that require secondary storage won't work (but I don't currently have any >>of those). >> >>The related messages from the server: >>2012-11-29 09:44:56,261 TRACE [db.Transaction.Connection] >>(consoleproxy-1:null) Creating a DB connection with no txn: for 0: >>dbconn1086427264. Stack: >>-Transaction.prepareStatement:453-Transaction.prepareAutoCloseStatement:4 >>4 >>6-GenericDaoBase.searchIncludingRemoved:380-DatabaseCallback.intercept:34 >>- >>GenericDaoBase.searchIncludingRemoved:342-DatabaseCallback.intercept:34-G >>e >>nericDaoBase.listIncludingRemovedBy:894-GenericDaoBase.listBy:871-Generic >>D >>aoBase.listBy:884-DataCenterDaoImpl.listEnabledZones:366-DatabaseCallback >>. >>intercept:34-ConsoleProxyManagerImpl.getScannablePools:1915 >>2012-11-29 09:44:56,261 TRACE [db.Transaction.Statement] >>(consoleproxy-1:null) Preparing: SELECT data_center.id, data_center.name, >>data_center.description, data_center.dns1, data_center.dns2, >>data_center.internal_dns1, data_center.internal_dns2, >>data_center.router_mac_address, data_center.guest_network_cidr, >>data_center.domain_id, data_center.domain, data_center.networktype, >>data_center.dns_provider, data_center.dhcp_provider, >>data_center.gateway_provider, data_center.vpn_provider, >>data_center.userdata_provider, data_center.lb_provider, >>data_center.firewall_provider, data_center.mac_address, >>data_center.zone_token, data_center.removed, >>data_center.allocation_state, data_center.uuid, >>data_center.is_security_group_enabled, >>data_center.is_local_storage_enabled FROM data_center WHERE >>data_center.allocation_state = ? AND data_center.removed IS NULL >>2012-11-29 09:44:56,264 TRACE [db.Transaction.Statement] >>(consoleproxy-1:null) Closing: >>org.apache.commons.dbcp.DelegatingPreparedStatement@63f5e4b6 >>2012-11-29 09:44:56,264 TRACE [db.Transaction.Connection] >>(consoleproxy-1:null) Closing DB connection: dbconn1086427264 >>2012-11-29 09:44:56,264 DEBUG >>[cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) Zone 1 >>is not ready to launch console proxy yet >>2012-11-29 09:44:56,265 TRACE [utils.db.GlobalLock] (consoleproxy-1:null) >>lock consoleproxy.scan.lock is returned to free state, total holding time >>:32 >>2012-11-29 09:44:56,265 TRACE [utils.db.GlobalLock] (consoleproxy-1:null) >>lock consoleproxy.scan.lock is released, lock count :0 >>2012-11-29 09:44:56,267 TRACE [utils.db.GenericDaoBase] >>(consoleproxy-1:null) Select SQL: SELECT stack_maid.id, stack_maid.msid, >>stack_maid.thread_id, stack_maid.seq, stack_maid.cleanup_delegate, >>stack_maid.cleanup_context, stack_maid.created FROM stack_maid WHERE >>2012-11-29 09:44:56,267 TRACE [utils.db.GenericDaoBase] >>(consoleproxy-1:null) Remove SQL: No remove sql >>2012-11-29 09:44:56,267 TRACE [utils.db.GenericDaoBase] >>(consoleproxy-1:null) Select by Id SQL: SELECT stack_maid.id, >>stack_maid.msid, stack_maid.thread_id, stack_maid.seq, >>stack_maid.cleanup_delegate, stack_maid.cleanup_context, >>stack_maid.created FROM stack_maid WHERE stack_maid.id = ? >> >> >>The systemVM was downloaded from >>http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.b >>z >>2 when my cloud was originally set up (which incidentally is the same as >>given in the installation instructions for 4.0-incubator). >> >>The system VM shows in the database as being DOWNLOADED: >> id: 3 >> host_id: 2 >> template_id: 3 >> created: 2012-10-24 23:56:42 >> last_updated: 2012-11-27 12:04:05 >> job_id: NULL >> download_pct: 100 >> size: 725811200 >> physical_size: 725811200 >>download_state: DOWNLOADED >> error_str: NULL >> local_path: NULL >> install_path: >>template/tmpl/1/3//b5d17e02-394a-4a01-bf13-6963b3127c39.qcow2 >> url: >>http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.b >>z >>2 >> destroyed: 0 >> is_copy: 0 >> >> >>My 3.0.2 CS installation ran perfectly since I set it up, but I'd really >>like to get 4.0-incubator up and running correctly. >> >>I've googled and tried pretty much everything I've found (which isn't >>much), but to no avail. I can't find any reason that the management >>server thinks the zone isn't ready to launch the system VMs. I've >>restarted the pod, the cluster, the hosts in the cluster, the zone, but I >>still have the issue. >> >>Any help would be appreciated. >> >>Jeff >
