Edison Su
> wrote:
> >>>
> >>> I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which
> >>> will fix some of the mess of vlan id.
> >>>
> >>> > -----Original Message-
> >>> > From: Marcus [mailto
If we get the 4.3.0 to 4.3.1 in then there is no need for my previous
comment. I was concerned it would not happen.
On Wed, Jun 4, 2014 at 9:20 AM, Daan Hoogland
wrote:
> On Wed, Jun 4, 2014 at 4:27 PM, Marcus wrote:
> > Regarding 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do
gt; >> (Updated June 7, 2014, 8:23 a.m.)
> >>
> >>
> >>
> >> Review request for cloudstack and Marcus Sorensen.
> >>
> >>
> >> Repository: cloudstack-git
> >>
> >>
> >> Description
> >> ---
> >&
; (Updated June 7, 2014, 8:23 a.m.)
>>
>>
>>
>> Review request for cloudstack and Marcus Sorensen.
>>
>>
>> Repository: cloudstack-git
>>
>>
>> Description
>> ---
>>
>>
>> VPC's VR missing public NIC eth1 as re
:
> https://reviews.apache.org/r/22093/
> ---
>
> (Updated June 7, 2014, 8:23 a.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
>
Sorensen.
Repository: cloudstack-git
Description
---
VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by updating
on upgrade
This fix might have to be included in a 4.3.0 to 4.3.1 upgrade as well
Diffs
-
engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430
Sorensen.
Repository: cloudstack-git
Description (updated)
---
VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by updating
on upgrade
This fix might have to be included in a 4.3.0 to 4.3.1 upgrade as well
Diffs
-
engine/schema/src/com/cloud/upgrad
Sorensen.
Repository: cloudstack-git
Description
---
VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by updating
on upgrade
This fix might have to be included in a 4.3.0 to 4.3.1 upgrade as well
Diffs
-
engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430
On Wed, Jun 4, 2014 at 4:27 PM, Marcus wrote:
> Regarding 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do
> that for IpAssocCommand as well.
I am feeling like in a spiral down. If the user input is fixed up
coming in it should probably be fixed down going out. when we save a
uri
>>> > -Original Message-
>>> > From: Marcus [mailto:shadow...@gmail.com]
>>> > Sent: Tuesday, June 03, 2014 9:57 AM
>>> > To: Daan Hoogland
>>> > Cc: dev
>>> > Subject: Re: VPC's VR missing public NIC eth1
>>
ess of vlan id.
>>
>> > -Original Message-
>> > From: Marcus [mailto:shadow...@gmail.com]
>> > Sent: Tuesday, June 03, 2014 9:57 AM
>> > To: Daan Hoogland
>> > Cc: dev
>> > Subject: Re: VPC's VR missing public NIC eth1
>> &g
Marcus [mailto:shadow...@gmail.com]
> > Sent: Tuesday, June 03, 2014 9:57 AM
> > To: Daan Hoogland
> > Cc: dev
> > Subject: Re: VPC's VR missing public NIC eth1
> >
> > Ok, thanks. It seems there are other cases where the Command being
> > passed from the mgmt s
I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which will fix
some of the mess of vlan id.
> -Original Message-
> From: Marcus [mailto:shadow...@gmail.com]
> Sent: Tuesday, June 03, 2014 9:57 AM
> To: Daan Hoogland
> Cc: dev
> Subject: Re: VPC'
Ok, thanks. It seems there are other cases where the Command being passed
from the mgmt server has inconsistent broadcastUri as well, this should
blanket fix them. In the meantime there's a growing group of 4.3 upgraders
who are getting pitchforks out over at CLOUDSTACK-6464, so we may want to
have
one clarification, I was not suggesting changing vlan://x back to x,
just the case where x==untagged. I had a little analog discussion with
Hugo and he convinced me that untagged has no special meaning in SDN
cases, maybe for vxlan. So the problem I saw is at least smaller then
in my mind.
I have
Just to recap... I was trying to review the issue in my head and thought it
might be useful to write it down.
in 4.3 we got the BroadcastDomainType enum introduced, and many parts of
the code were changed to use that when dealing with the vlan id. This code,
among other things, returns a vlan id i
I'm not sure the KVM code needs to be changed, you're asking it to deal
with an inconsistency from the mgmt server. Don't you find it odd that one
Command from the mgmt server provides broadcastUri="vlan://untagged" and
another provides broadcastUri="untagged"? I'm not sure I understand why
changi
udstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by
> updating on upgrade
>
>
> Diffs
> -
>
> engine/schema/src/com
Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by
> updating on upgrade
>
>
> Diffs
> -
>
> engine
4, 9 p.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by
> updating on upgrade
>
>
I don't think this should be solved this way afterall. 'untagged'
actually means no vlan, so it should not be prepended with 'vlan://'.
I think the kvm code should be fixed for this not the generic code.
On Fri, May 30, 2014 at 10:59 PM, Daan Hoogland wrote:
> On Fri, May 30, 2014 at 10:51 PM, Ma
pache.org/r/22093/
> ---
>
> (Updated May 30, 2014, 9 p.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> VPC's VR missing public NIC eth1 as rep
ted e-mail. To reply, visit:
> https://reviews.apache.org/r/22093/
> ---
>
> (Updated May 30, 2014, 9 p.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
d May 30, 2014, 9 p.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by
> updating on upgrade
>
-mail. To reply, visit:
> https://reviews.apache.org/r/22093/
> ---
>
> (Updated May 30, 2014, 9 p.m.)
>
>
> Review request for cloudstack and Marcus Sorensen.
>
>
> Repository: cloudstack-git
>
>
> De
Sorensen.
Changes
---
debug statement
Repository: cloudstack-git
Description
---
VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by updating
on upgrade
Diffs (updated)
-
engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132
Diff:
On Fri, May 30, 2014 at 10:51 PM, Marcus wrote:
> Looks good to me, aside from he debug statement.
Ah, the first line was not in my line of sight.
--
Daan
Description
---
VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by updating
on upgrade
Diffs
-
engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132
Diff: https://reviews.apache.org/r/22093/diff/
Testing
---
Thanks,
daan Hoogland
It's not valid if you've got code that says does string 'vlan://untagged'
equal 'untagged'.
On Fri, May 30, 2014 at 10:17 AM, Daan Hoogland
wrote:
> CLOUDSTACK-5505 looks alright. As for the solution; Isn't 'untagged' a
> valid uri in itself? I would expect it would have always the value
> with
I agree, I actually brought this issue up several months ago when we had
all of the 'untagged' discussions. I believe I pointed out that vlan:// was
now in the db. My impression was that the change was intentional, if you're
telling me you didn't intend to do that then we can change it back.
At t
CLOUDSTACK-5505 looks alright. As for the solution; Isn't 'untagged' a
valid uri in itself? I would expect it would have always the value
without the 'vlan://'. That said a solution is better then no
solution, maybe the db upgrade path is best.
Andrija, can you try as Marcus suggests, editing the
If that works, then I think the fix is better to update the database
upgrade script to look for this and change the vlan_id. That way new
installs and upgrades have consistent data. We could fix it in the code by
filtering it through BroadcastDomainType.Vlan.toUri(ipAddr.getVlanTag()),
but then lat
Marcus, I don't think it should be 'vlan://untagged'. If it works as
you describe this seems a bug. 'untagged' should be
broadcastdomaintype agnostic, shouldn't it?
If it should work that way then it is a bug/omission in the db upgrade.
On Fri, May 30, 2014 at 5:57 PM, Marcus wrote:
> Actually, i
Actually, if you're in the position to play a bit... New deployments seem
to work, and I believe it's because that broadcastUri is stored in the db
in the new format:
mysql> select id,vlan_id from vlan where network_id = (select id from
networks where traffic_type="Public");
++---
I thinnk the commit that caused the change was this or related to it. Is
there any way you could test a fix? Do you need me to build 4.3 RPMs or can
I just provide a patch? What works for you?
commit 53d09c6f1843f04c5f1ab76be9419f5584302d1e
Date: Mon Aug 5 11:52:40 2013 +0200
uri code per b
Note the differences in broadcastUri, here is your plug command:
{
"com.cloud.agent.api.PlugNicCommand": {
"nic": {
"deviceId": 1,
"networkRateMbps": 9,
"defaultNic": true,
"uuid": "6c782af3-2071-4543-acdc-cb30096e89ff",
"
I believe I've found the issue. In 4.3, some changes were made to
BroadcastDomainType, to standardize Broadcast URIs to prepend vlan://. The
issue is that your IpAssocVpcCommand doesn't use this new format for the
broadcastUri it passes, so it fails to map the plugged device into the
broadcastUriT
yes, correct, eth1 is present, and can be started by static IP
configuration...
On 30 May 2014 17:25, Marcus wrote:
> Let me make sure I understand... the 'Plug' of the nic works fine, as it
> seems you do have an eth1 and can manually assign the IP to get it to work?
> If that's the case then
Let me make sure I understand... the 'Plug' of the nic works fine, as it
seems you do have an eth1 and can manually assign the IP to get it to work?
If that's the case then there's probably not an issue in BridgeVifDriver or
the XML. It is definitely in fetching/matching the eth device here
vpc_ip
Nope, started, did check, it is reported now as Debian 5 VM, but still
doesn't work...
Rebooted VPC (destroyed VR, new one created...)
$ virsh dumpxml r-812-VM
...
Debian GNU/Linux 5(64-bit)
...
hvm
:(
On 30 May 2014 16:24, Andrija Panic wrote:
> I confirm, the highest is
I confirm, the highest is Debian 5 64bit
Per docs
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.3/rnotes.html#upgrade-from-4-2-x-to-4-3
, you should use Debian 7.0 64bit as OS type for system-kvm-4.3 template...
(same for xen and vmware templatest)
Will change now DB to
Andrija,
The thing is I don't know who the os matching on KVM works. There must be
a way to list supported os types.
I also did some queuing on the guest_os_hypervisor table (ACS 4.3) and I
don't see Debian 7 for KVM listed.
select * from guest_os join guest_os_hypervisor on
guest_os.id=guest_os
Joris,
do you have recommendation on how in particular to try ? I'm not sure how
to fix that, except playing with editing systemvm-4.3 template to define it
as another OS type... ?
Thanks again,
Andrija
On 30 May 2014 15:30, Joris van Lieshout
wrote:
> I've read back a bit in the code and if
I've read back a bit in the code and if you look at BridgeVifDriver.java
(this is where the log message with the nic profile is generated) you can
see that the nic information might be off already once ACS hits the
LibvirtVMDef.InterfaceDef plug function. This leads be to believer that
the HVM/PV O
OK, thanks Joris.
I will try playing with OS version option, on the systemvm-kvm-4.3
template...
Let me know if I can help with anything more.
Thanks.
Andrija
On 30 May 2014 15:19, Joris van Lieshout
wrote:
> Hi Andrija,
>
> That does sound familiar and in the start xml of KVM you can see "
Hi Andrija,
That does sound familiar and in the start xml of KVM you can see "hvm". I don't know KVM+ACS well enough
to judge if this is the cause but I thing focusing on getting the VR
started as PV guest might be worth trying. On the other hand I do see
patchviasocket.pl being executed successfu
Hi Joris,
I have turned on DEBUG loging in agent.log on cs1.xxx/net host:
So, management logs again: http://pastebin.com/F6BRf7Y9
Agent logs on cs1.xxx: http://pastebin.com/BJauKbaC
Not playing smart, but there is some error: [kvm.resource.KVMGuestOsMapper]
(agentRequest-Handler-3:) Can't find t
Hi Andrija,
Bold formatting does not come trough on the dev list. :)
But u might need a bit more info.
At a certain point I see this line
2014-05-30 13:56:23,935 DEBUG [c.c.a.t.Request]
(Job-Executor-77:ctx-ec3d358e ctx-f35b12af) Seq 1-609104082: Sending {
Cmd , MgmtId: 161344838950, via: 1(cs1
Hi Joris,
here is the management log: http://pastebin.com/zxnKxFhk
Interesting parts (to me): in bold
2014-05-30 13:56:21,899 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-77:ctx-ec3d358e ctx-f35b12af) copyAsync inspecting src type
TEMPLATE copyAsync inspecting dest type VOLUME
2014-
Hi Andrija,
Just the start of the VR should be sufficient.
Kind regards,
Joris van Lieshout
Schuberg Philis
Boeingavenue 271
1119 PD Schiphol-Rijk
schubergphilis.com
+31 20-7506672
+31 6-51428188
On 30/05/14 13:48, "Andrija Panic" wrote:
>Hi Joris,
>
>just to be sure - you want me to cap
Hi Joris,
just to be sure - you want me to capture the log from the moment I reboot
router - or you want me to stop it, then start capturing log, and start it
(and continue capture untill ethnull errors inside VR) ?
Thanks,
On 30 May 2014 13:39, Joris van Lieshout
wrote:
> Hi Andrija,
>
> Tha
Hi Andrija,
Thanks for the answers. In deed your situation is different so PV/HVM is
not the issue.
When reading back the log output you have provided I noted that the VR
messages log indicates that it's waiting for ethnull to be up. This raises
the question where null was introduced instead of 1
Hi Deen,
no, in DB there is field "vlan_id" with value "untagged" - that
"vlan://untagged" is shown from ACS gui, and is used in API call (or better
said commands that are seen in management server logs).
Best,
Andrija
On 30 May 2014 10:37, Daan Hoogland wrote:
> Andrija,
>
> Do not just assig
Andrija,
Do not just assign a second net vlan://500 You have one like that and
you don't want conflicting nets using the same vlan. I am wondering
why 'untagged' comes out as 'vlan://untagged'. I think that is the
bug. Did you find the string 'vlan://untagged' in your db?
On Fri, May 30, 2014 at
Hi Joris,
thank you for taking time to address this issue :)
So...:
- I'm on KVM (stock CentOS 6.2 patched by Inktank for CEPH support), OS is
Centos 6.5, libvirt 1.2.3 compiled.
- ACS 4.3 having problems, ACS 4.2.1 was fine
- not XS, so I guess no answers for this part :)
- guest_os_id is 184 =
Hi Andrija,
Daan asked me to have a look at this as well. Looking at you issue I
recall having seen something similar. Back then when upgrading 4.2.1 to
4.3 I though it had to do with out own custom build svm template.
Let me fire off some questions before explaining what the cause was in our
case
They are 2 traffic types on 1 physical net (that is both tagged vlan 500,
and untagged packets travel over same KVM bridge, and over eth1 to outside
world)...
On 29 May 2014 12:04, Daan Hoogland wrote:
> Are these two traffic types in one physical net? or two physical nets
> on the same interfa
Are these two traffic types in one physical net? or two physical nets
on the same interface (seems wrong).
On Thu, May 29, 2014 at 11:35 AM, Jayapal Reddy Uradi
wrote:
> I don't think editing DB table will work.
>
> -Jayapal
> On 29-May-2014, at 2:52 PM, Andrija Panic wrote:
>
>> It's like this:
I don't think editing DB table will work.
-Jayapal
On 29-May-2014, at 2:52 PM, Andrija Panic wrote:
> It's like this:
>
> I have public subnet /24.
>
> half is dedicated for Guest traffic (vlan 500) and the second half is
> dedicated to Public traffic/network (no vlan tags, that is untagged pa
It's like this:
I have public subnet /24.
half is dedicated for Guest traffic (vlan 500) and the second half is
dedicated to Public traffic/network (no vlan tags, that is untagged packets)
Both vlan500 and untagged packets travel over physical eth1 interface on
hypervisors and can reach Internet
On Thu, May 29, 2014 at 10:57 AM, Andrija Panic wrote:
> 500
is 500 the vlan of your guestnetwork or your physical network? You
wouldn't want to have two nets with vlan 500!
--
Daan
.@gmail.com>>
> >> >> > wrote:
> >> >> > Hi Daan,
> >> >> >
> >> >> > I don't think this is my issue, at least I don't make use of
> private
> >> >> &g
com>>
>> >> > wrote:
>> >> > Hi Daan,
>> >> >
>> >> > I don't think this is my issue, at least I don't make use of private
>> >> > gateway - this is just simple as: create new VPC from scratch -
&
ake use of private
> >> > gateway - this is just simple as: create new VPC from scratch -
> Public
> >> > IP
> >> > is not assigned to VR eth1 interface inside VR...
> >> >
> >> > I have filed the bug:
> >> > https://issues.apache
IP
>> > is not assigned to VR eth1 interface inside VR...
>> >
>> > I have filed the bug:
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-6801
>> >
>> > This same thing happened previously to Andrei Mikhailovsky:
>> >
>> >
ailovsky:
> >
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-users/201405.mbox/%3C33347835.250.1399336340785.JavaMail.andrei@tuchka%3Eand
> > it is not resolved
> >
> > Thanks,
> >
> > Andrija
> >
> >
> > On 28 May 2014 21:01,
t;
> Andrija
>
>
> On 28 May 2014 21:01, Daan Hoogland wrote:
>
> Andrija,
>
> this sound like something we seen as well.
> can you check if this is it :
> https://issues.apache.org/jira/browse/CLOUDSTACK-6485
>
> thanks,
> Daan
>
> On Wed
;t make use of private
gateway - this is just simple as: create new VPC from scratch - Public
IP
is not assigned to VR eth1 interface inside VR...
I have filed the bug:
https://issues.apache.org/jira/browse/CLOUDSTACK-6801
This same thing happened previously to Andrei Mikhailovsky:
http://mail
4.3.1 - did not found this filed as bug so
> far...and
> >> > it worked all fine on ACS 4.2.1.
> >> >
> >> > No help so far from user mailing list...
> >> >
> >> > Below is a detailed explanation, and logs from inside VR,
a detailed explanation, and logs from inside VR, and from
>> > management (all fine with management logs...)
>> >
>> > If anybody can help, I would very much appriciate this, since now I have
>> > bunch fo VPC unoperational...
>> >
>> > Thanks
>&
from inside VR, and from
> > management (all fine with management logs...)
> >
> > If anybody can help, I would very much appriciate this, since now I have
> > bunch fo VPC unoperational...
> >
> > Thanks
> >
> > -- Forwarded message --
ent logs...)
>
> If anybody can help, I would very much appriciate this, since now I have
> bunch fo VPC unoperational...
>
> Thanks
>
> -- Forwarded message --
> From: Andrija Panic
> Date: 28 May 2014 14:50
> Subject: Re: VPC's VR missing pu
de VR, and from
management (all fine with management logs...)
If anybody can help, I would very much appriciate this, since now I have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public
73 matches
Mail list logo
