You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by cs user <ac...@gmail.com> on 2015/03/26 13:31:03 UTC

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

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 <La...@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/
>

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by cs user <ac...@gmail.com>.
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 <da...@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 <ac...@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 <ac...@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
>

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by sandeep khandekar <cl...@gmail.com>.
Great job! Does it works after making changes?

On Thu, Mar 26, 2015 at 6:07 PM, Daan Hoogland <da...@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 <ac...@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 <ac...@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

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by Daan Hoogland <da...@gmail.com>.
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 <ac...@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 <ac...@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 <La...@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

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by Daan Hoogland <da...@gmail.com>.
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 <ac...@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 <ac...@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 <La...@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

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by cs user <ac...@gmail.com>.
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 <ac...@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 <La...@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/
>>
>
>

Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2

Posted by cs user <ac...@gmail.com>.
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 <ac...@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 <La...@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/
>>
>
>