cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cs user <acldstk...@gmail.com>
Subject Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
Date Fri, 27 Mar 2015 13:49:36 GMT
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.sandeep@gmail.com> wrote:

> Great job! Does it works after making changes?
>
> On Thu, Mar 26, 2015 at 6:07 PM, Daan Hoogland <daan.hoogland@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 <acldstkusr@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 <acldstkusr@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.Steff@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message