cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
Date Thu, 26 Mar 2015 12:37:45 GMT
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

Mime
View raw message