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/ >> > >
