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 daan.hoogl...@gmail.com
wrote:
On Wed, Jun 4, 2014 at 4:27 PM, Marcus shadow...@gmail.com wrote:
Regarding
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's VR missing public NIC eth1
Ok, thanks. It seems there are other cases where
.
-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
Ok, thanks. It seems there are other cases where the Command being
passed from the mgmt server has
: 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 server has inconsistent broadcastUri as well, this
should blanket fix them. In the meantime there's
On Wed, Jun 4, 2014 at 4:27 PM, Marcus shadow...@gmail.com 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.
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
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
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's VR missing public NIC eth1
[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 server has inconsistent broadcastUri as well, this
should blanket fix
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 daan.hoogl...@gmail.com wrote:
On Fri, May
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
changing
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
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
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
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 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
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
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 andrija.pa...@gmail.com wrote:
Hi Joris,
just to be sure -
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
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:
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
Hi Andrija,
That does sound familiar and in the start xml of KVM you can see type
arch='x86_64' machine='pc'hvm/type. 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
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 jvanliesh...@schubergphilis.com
wrote:
Hi Andrija,
That does sound familiar and in the
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
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 jvanliesh...@schubergphilis.com
wrote:
I've read
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
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
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
...
descriptionDebian GNU/Linux 5(64-bit)/description
...
os
type arch='x86_64' machine='rhel6.5.0'hvm/type
boot dev='cdrom'/
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
yes, correct, eth1 is present, and can be started by static IP
configuration...
On 30 May 2014 17:25, Marcus shadow...@gmail.com 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
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
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,
ip:
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
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);
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 shadow...@gmail.com
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
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
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
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 daan.hoogl...@gmail.com
wrote:
CLOUDSTACK-5505 looks alright. As for the solution; Isn't 'untagged' a
valid uri in itself? I would expect it would have
On Fri, May 30, 2014 at 10:51 PM, Marcus shadow...@gmail.com wrote:
Looks good to me, aside from he debug statement.
Ah, the first line was not in my line of sight.
--
Daan
andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive|
Transmit
face |bytes
2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive|
Transmit
face |bytespackets errs drop fifo frame
unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present
On Thu, May 29, 2014 at 10:57 AM, Andrija Panic andrija.pa...@gmail.com 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
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
I don't think editing DB table will work.
-Jayapal
On 29-May-2014, at 2:52 PM, Andrija Panic andrija.pa...@gmail.com 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,
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
jayapalreddy.ur...@citrix.com wrote:
I don't think editing DB table will work.
-Jayapal
On 29-May-2014, at 2:52 PM, Andrija Panic
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 daan.hoogl...@gmail.com wrote:
Are these two traffic types in one physical net? or two physical
can help, I would very much appriciate this, since now I have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
help, I would very much appriciate this, since now I have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive
have
bunch fo VPC unoperational...
Thanks
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present
-- Forwarded message --
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive
--
From: Andrija Panic andrija.pa...@gmail.com
Date: 28 May 2014 14:50
Subject: Re: VPC's VR missing public NIC eth1
To: us...@cloudstack.apache.org
and as I said eth1 is present:
root@r-794-VM:~# cat /proc/net/dev
Inter-| Receive
55 matches
Mail list logo
