Great; if you need any help do not hesitate to reach us here.
On Wed, Aug 2, 2017 at 11:20 AM, Rodrigo Baldasso
wrote:
> Yes, it is. I'll try to find out the main reason for that happen and if
> find a way to fix the code, share here.
>
> Thanks.
>
> - - - - - - - - - - - - - - - - - - -
>
> Rod
Yes, it is. I'll try to find out the main reason for that happen and if find a
way to fix the code, share here.
Thanks.
- - - - - - - - - - - - - - - - - - -
Rodrigo Baldasso - LHOST
(51) 9 8419-9861
- - - - - - - - - - - - - - - - - - -
On 02/08/2017 11:16:47, Rafael Weingärtner wrote:
Ah, t
Ah, that is what I wanted to check now ...
I was going to ask you to execute the following SQL:
select v.* from pod_vlan_map vlanMap
join vlan v on v.id = vlanMap.vlan_db_id
where v.removed is null and vlanMap.pod_id = 1
So, now everything is ok for you?
On Wed, Aug 2, 2017 at 11:13 AM, R
Confirmed: when the pod has more than one vlan on the vlan table, it throws
this exception error. I've deleted all vlans leaving only the one with ID 14
(that i created for this test) and was able to sucessfully delete the pod.
Maybe the code doesn't handle more than one match of pod <> vlans, a
ID of problematic pod: 1
4 is the ID of the working pod. However all settings between them are
identical. The problem seems to be when one pod has *more* than one vlan
(deleted or not).
- - - - - - - - - - - - - - - - - - -
Rodrigo Baldasso - LHOST
(51) 9 8419-9861
- - - - - - - - - - - - - -
What is the ID of the pod you want to remove? 1 or 4?
On Wed, Aug 2, 2017 at 11:03 AM, Rodrigo Baldasso
wrote:
> Yep: http://prntscr.com/g3gab3
>
> - - - - - - - - - - - - - - - - - - -
>
> Rodrigo Baldasso - LHOST
>
> (51) 9 8419-9861
> - - - - - - - - - - - - - - - - - - -
> On 02/08/2017 11:0
Yep: http://prntscr.com/g3gab3
- - - - - - - - - - - - - - - - - - -
Rodrigo Baldasso - LHOST
(51) 9 8419-9861
- - - - - - - - - - - - - - - - - - -
On 02/08/2017 11:02:40, Rafael Weingärtner wrote:
I mean, I said 14 because this was the one select by you. Can you check the
VLAN table searching
I mean, I said 14 because this was the one select by you. Can you check the
VLAN table searching by ID (vlan_db_id) from VLAN map table of the pod that
you are having problems to remove.
On Wed, Aug 2, 2017 at 11:00 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> Interesting; now,
Interesting; now, can you try to find a vlan with ID=14 in "vlan" table?
On Wed, Aug 2, 2017 at 10:58 AM, Rodrigo Baldasso
wrote:
> Sure: http://prntscr.com/g3g7iu
>
> The last vlan map is the one that I created for testing on the problematic
> pod.
>
> - - - - - - - - - - - - - - - - - - -
>
>
Sure: http://prntscr.com/g3g7iu
The last vlan map is the one that I created for testing on the problematic pod.
- - - - - - - - - - - - - - - - - - -
Rodrigo Baldasso - LHOST
(51) 9 8419-9861
- - - - - - - - - - - - - - - - - - -
On 02/08/2017 10:56:01, Rafael Weingärtner wrote:
Can you also l
Can you also list the table "pod_vlan_map" for all of the "maps" of vlans
for the given POD?
On Wed, Aug 2, 2017 at 10:40 AM, Rodrigo Baldasso
wrote:
> I've created a new vlan/ip pool just for this test (had already removed
> all ip pool before), the problem persisted.
>
> here is how the new vl
I've created a new vlan/ip pool just for this test (had already removed all ip
pool before), the problem persisted.
here is how the new vlan looks like in my db:
http://prntscr.com/g3fxt1
It's pretty equals to the one of the working pod.
- - - - - - - - - - - - - - - - - - -
Rodrigo Baldass
Ok,
Following the code where the null pointer happens at line 163:
https://github.com/apache/cloudstack/blob/0e057ad69edab9f1664924ac1fb2500ca799cfb6/engine/schema/src/com/cloud/dc/dao/VlanDaoImpl.java
can you list all VLANs in "vlan" table that have the PODid equals one of
the Pods you want to r
This pod got somewhat corrupted when I change it's IP pool allocation cidr.
After changing, it didn't started the SSVM's with the nullpointer error that
i've send before and now the pod can't be deleted, also throwing the
nullpointer error.
Thanks.
- - - - - - - - - - - - - - - - - - -
Rodrig
Well, looking at the data you posted, the problem should not happen. Let´s
take step back. Can you describe briefly what you are trying to do, and
what problem you are having now?
On Wed, Aug 2, 2017 at 9:17 AM, Rodrigo Baldasso
wrote:
> Hi Rafael,
>
> I checked this table yesterday and couldn't
Hi Rafael,
I checked this table yesterday and couldn't find nothing wrong.. i made a line
around the vLan of the new pod (that is working). The other vLans are from the
pod that i'm unable to delete and didn't booted the SSVM's. They have the
column 'removed' with the date that i deleted them.
Rodrigo,
There is an inconsistency in your database.
To get this null pointer, the column "vlan_type" of table "vlan" must be
null or something unrecognized in the database. Can you check this table?
On Tue, Aug 1, 2017 at 1:03 PM, Rodrigo Baldasso
wrote:
> Thank you.
>
> This is the log when
Thank you.
This is the log when I try to delete this pod, if it helps.
2017-08-01 13:03:01,361 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-262022ac)
(logid:91c02e8f) ===START=== 186.250.14.20 -- GET
command=deletePod&id=39e23530-0553-4b54-948d-5da00c4952c2&response=json&_=1501603382823
2017
It might be a bug then.
I will try to connect the dots. The problem seems to be with the pod then.
2017-08-01 12:01 GMT-03:00 Rodrigo Baldasso :
> Hi, thanks for your reply
>
> I didnt made any changes manually on the database, however, it's like the
> pod got corrupted after the change. I can't
Hi, thanks for your reply
I didnt made any changes manually on the database, however, it's like the
pod got corrupted after the change. I can't even delete the pod from the
zone that throws the exception (nullpointer) also.
I was able to reproduce that in a fresh, clean install. So maybe it's a b
You said that it worked before changing the IP range; it might be caused by
a database inconsistency related to the IP allocation. Did you make any
manual changes in the database?
The null pointer exception came after the following methods exectution:
1 - it begins the exectution flow to start the
Thanks for your reply.
I'm using 4.9.2.0. I'm posting the full log below!
The secondary storage is mounted as NFS.
PS: i was able to start SSVM after creating a new zone, however, when I
changed the IP range, the error came back again.
2017-07-31 13:23:15,950 DEBUG [c.c.a.t.Request]
(Work-Job-E
Hi Rodrigo,
Which version of CloudStack are you using? Is there any exception stack in
the log? Are you using advanced or basic network? Is there any connection
problem?
Are you using Swift as Secondary Storage? If yes, there is an open issue
"CLOUDSTACK-7443: Cannot launch SSVMs when using Swift
23 matches
Mail list logo