Sandeep, We are now able to launch system vm's and normal instances, but are now faced with this problem:
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201503.mbox/%3CCADfcUwGiJk6iXbgeZ7gQ-Tummfo1KmLVdf2WP%2Bzci2MmrfM5HA%40mail.gmail.com%3E Thanks! On Fri, Mar 27, 2015 at 10:16 AM, sandeep khandekar < cloudstack.sand...@gmail.com> wrote: > Great job! Does it works after making changes? > > On Thu, Mar 26, 2015 at 6:07 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > 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 > > > > > > -- > SANDEEP KHANDEKAR > Assistant Professor > Department of Computer science and engineering > Sreenidhi Institute of science and Technology > Hyderabad >
