You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Laurent Steff <La...@inria.fr> on 2015/02/23 13:40:27 UTC
WARNING for users migrating from Cloudstack 4.2 to 4.4.2
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/
>>
>
>
Re: WARNING for users migrating from Cloudstack 4.2 to 4.4.2
Posted by cs user <ac...@gmail.com>.
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>.
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/
>