Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of acldstkusr@gmail.com
 designates 209.85.218.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <139818582.4410709.1424695227242.JavaMail.zimbra@inria.fr>
References: <1512034742.4332721.1424692818897.JavaMail.zimbra@inria.fr>
	<139818582.4410709.1424695227242.JavaMail.zimbra@inria.fr>
Date: Thu, 26 Mar 2015 12:31:03 +0000
Message-ID: 
 <CADfcUwEp6_N01pSGrA3Jod2gNwswBTisXhedUpWXDv05WEywpw@mail.gmail.com>
Subject: Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
From: cs user <acldstkusr@gmail.com>
To: dev@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=001a113ced40677a360512303045

--001a113ced40677a360512303045
Content-Type: text/plain; charset=UTF-8

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

--001a113ced40677a360512303045--