thanks for the HEADsup, can you guys test 4.4.3 and confirm whether it solves CLOUDSTACK-7399?
this kind off feedback is not spam but much appriciated and hereby solicited. On Thu, Mar 26, 2015 at 1:33 PM, cs user <acldstk...@gmail.com> wrote: > Just to clarify, the fix was: > > update networks set broadcast_uri="vlan://untagged" where mode='Dhcp'; > > As these were set to null. > > Sorry for the spam! > > On Thu, Mar 26, 2015 at 12:31 PM, cs user <acldstk...@gmail.com> wrote: > >> Hi Laurent, >> >> Many many thanks for this. We had the exact same problem but using >> xenserver as hosts. The fix for us was: >> >> select name,broadcast_uri from networks where mode='Dhcp'; >> >> We were using basic networking as well. >> >> We had upgraded from 4.3 to 4.4.2, using Xenserver 6.1. >> >> Thank you!!!!!!! >> >> On Mon, Feb 23, 2015 at 12:40 PM, Laurent Steff <laurent.st...@inria.fr> >> wrote: >> >>> Hi, >>> >>> This mail to share a fight we had at INRIA upgrading our Cloudstack/KVM >>> farm >>> from 4.2 to 4.4.2 following this documentation : >>> >>> >>> http://cloudstack-release-notes.readthedocs.org/en/latest/upgrade/upgrade-4.2.html >>> >>> It's now solved, but I would like to share, as I think : >>> >>> - it could helps other people like us who have already migrated from >>> Cloudstack 3.X to 4.X >>> - there is one bug marked as fixed and it should not >>> https://issues.apache.org/jira/browse/CLOUDSTACK-7399 >>> - a little documentation is missing (how to test if we have the good >>> qemu-kvm version for systemVMs templates) >>> >>> Here are the (long) details >>> >>> Technical informations : >>> ------------------------ >>> >>> - Upgrade from Cloudstack 4.2.1 to 4.4.2 >>> - CentOS 6/KVM for agents >>> - official Cloudstack rpms >>> - 1 zone with BasicNetworking >>> >>> We are using cloudstack here in two environnments : >>> >>> - qualification, with MS and agents created on 4.2.1 >>> - production, with MS and agents originally created on 3.x version, long >>> time ago before >>> Apache :D >>> >>> >>> Qualification troubles and solution : >>> ------------------------------------- >>> >>> - systemVM do not start after cloudstack-sysvmadm launch >>> - Solution was tu upgrade the KVM agents from Centos 6.3 to 6.6 >>> - we think (not sure) that we had a trouble with an historical qemu-kvm >>> version, and a good test >>> to document may be : what version of CentOS qemu-kvm supports, launching >>> this command : >>> --- >>> /usr/libexec/qemu-kvm -M ? >>> --- >>> >>> >>> Production troubles and solution : >>> ---------------------------------- >>> >>> - cloudstack-sysvmadm takes hours to shutdown, upgrade and restart >>> systemVM (2 or 3 hours) >>> - starting/stopping existing instances works >>> - but we're unable to create new instances (error on MS : >>> --- >>> com.cloud.exception.AgentUnavailableException: Resource [Host:xx] is >>> unreachable: Host xx: Unable to start >>> instance due to Unable to get answer that is of class >>> com.cloud.agent.api.StartAnswer >>> --- >>> - when destroyed manually, systemVM won't restart >>> - debug on agents shows the same message as this bug : >>> https://issues.apache.org/jira/browse/CLOUDSTACK-7399 >>> which is officially resolved in 4.4.1 (our version is 4.4.2 !!!) >>> --- >>> WARN [cloud.agent.Agent] (agentRequest-Handler-2:null) Caught: >>> java.lang.NullPointerException >>> at >>> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159) >>> ... >>> DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Seq >>> 25-6233544834234187813: { Ans: , MgmtId: 345044038925, via: 25, Ver: v1, >>> Flags: 10, >>> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat >>> com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:159)\n\tat >>> com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:213)\n\tat >>> com.cloud.hypervisor. >>> ... >>> --- >>> - we had to find our bascicnetwork in mysql table networks, whom >>> broadcast_uri was NULL >>> - and modify it to the "new" style vlan://untagged : >>> --- >>> update networks set broadcast_uri="vlan://untagged" where id="our >>> bascinetwork id"; >>> >>> Hope it could help, >>> >>> -- >>> Laurent Steff >>> >>> DSI/SESI >>> INRIA >>> http://www.inria.fr/ >>> >> >> -- Daan
