cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrija Panic <andrija.pa...@gmail.com>
Subject Re: VPC's VR missing public NIC eth1
Date Fri, 30 May 2014 08:48:03 GMT
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 <daan.hoogland@gmail.com> wrote:

> 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 10:20 AM, Andrija Panic <andrija.panic@gmail.com>
> wrote:
> > 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 = Debian 7 x64
> > - SVM = systemvm-kvm-4.3 = os type 184 = Debian 7 x64
> >
> > This worked previously on 4.2.1 = template was ofcourse systemvm-kvm-4.2
> -
> > but that was also Debian 7 x64 type... so this should not be the issues
> > (guest not supported by host...)
> >
> > The only thing that might be out of "standard" = all SVMs are on CEPH -
> > there are official docs on altering database to make some new System
> > Offering as default for SSVM and CPVM - what I did, I also have done same
> > config in DB, to make VR use another System Offering as default - which
> is
> > NOT explained in the docs - you could use "Change Offering..." button on
> > exiting, shutdown VR to change it per docs...
> > But still this worked all fine on 4.2.1...
> >
> > - regarding /var/cache/cloud/cmdline the content is folowing at the
> moment
> > root@r-801-VM:~# cat /var/cache/cloud/cmdline
> > vpccidr=10.0.0.0/8 domain=cscloud.internal dns1=8.8.8.8 dns2=
> template=domP
> > name=r-801-VM eth0ip=169.254.0.75 eth0mask=255.255.0.0 type=vpcrouter
> > disable_rp_filter=true
> >
> > Also please note that only eth1 does not have IP info, eth0 (control
> > 169.xxx) and all other eh2 and up that are used for Tiers get IP info
> fine.
> > I could also manually add IP for eth1 (public NIC) and start ifup eth1 -
> > and it works fine, but adding new IP Port Forwarding etc does not work...
> >
> > Daan or somebody said it could be realted to my "Public" network (in the
> > Zones, Physical Network, eth1 listing) is NOT tagged (vlan://untagged)...
> > Interestingly the only VR that does work fine is the VR used in Shared
> > network, but that VR is using IP from Guest IP range (also efectively
> > public IPs but on vlan 500)
> >
> > I was instructed to try to change Public IP range from untagged to vlan
> > 500, but I'm not sure how to do this, if there is any way at all (editing
> > "vlan" table and changing to vlan 500 does not work, after rebooting VR
> > from ACS gui).
> >
> > :)
> >
> > So, not sure what is roughly expected date for 4.4, but right now, I'm
> > pretty stuck with a big problem of all VPC not operational at all...
> >
> > Thanks,
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 30 May 2014 08:27, Joris van Lieshout <
> JvanLieshout@schubergphilis.com>
> > wrote:
> >
> >> 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. :)
> >>
> >> - what hypervisor (and version) are you using?
> >> - if XS, is the new VR a para-virtualised instance (PV) or hardware
> >> assisted (HVM)? Do a "xe vm-param-list" on the VR uuid and check that
> >> param PV-args is set and HVM-boot-policy is unset.
> >> - what is the OS type of the VR in ACS (guest_os_id in vm_instance table
> >> and match with table guest_os)
> >> - what is the OS type of the SVM template?
> >>
> >> Now for the explaining. :)
> >> In our case the OS type of the new template was not supported on the
> >> XenServer version we are running. Therefore the VR was started by XS as
> a
> >> HVM guest. System vms on XS rely on the arguments passed to them in the
> >> PV-args param (ends up on the guest in /var/cache/cloud/cmdline which in
> >> turn is used by cloud-early-config) in order to work. cmdline contains
> the
> >> NIC configuration information.
> >> So, long story short, if a VR gets started as a HVM it will not get the
> >> information needed to configure it's NICs.
> >>
> >> Workaround
> >> We corrected the os_type_id in the DB (yes I know editing the DB is
> >> something you usually don't want but there is no other way in this case)
> >> of the existing VR's and of the systemvmtemplate to something supported
> by
> >> XenServer.
> >>
> >> Kind regards,
> >> Joris van Lieshout
> >>
> >> Schuberg Philis
> >>
> >>
> >>
> >>
> >> On 29/05/14 12:18, "Andrija Panic" <andrija.panic@gmail.com> wrote:
> >>
> >> >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.hoogland@gmail.com> wrote:
> >> >
> >> >> 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.uradi@citrix.com> wrote:
> >> >> > I don't think editing DB table will work.
> >> >> >
> >> >> > -Jayapal
> >> >> > On 29-May-2014, at 2:52 PM, Andrija Panic <andrija.panic@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, that is
> untagged
> >> >> packets)
> >> >> >>
> >> >> >> Both vlan500 and untagged packets travel over physical eth1
> >> >>interface on
> >> >> >> hypervisors and can reach Internet.
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >>
> >> >> >> On 29 May 2014 11:06, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
> >> >> >>
> >> >> >>> On Thu, May 29, 2014 at 10:57 AM, Andrija Panic <
> >> >> andrija.panic@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
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >>
> >> >> >> Andrija Panić
> >> >> >> --------------------------------------
> >> >> >>  http://admintweets.com
> >> >> >> --------------------------------------
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Daan
> >> >>
> >> >
> >> >
> >> >
> >> >--
> >> >
> >> >Andrija Panić
> >> >--------------------------------------
> >> >  http://admintweets.com
> >> >--------------------------------------
> >>
> >>
> >
> >
> > --
> >
> > Andrija Panić
> > --------------------------------------
> >   http://admintweets.com
> > --------------------------------------
>
>
>
> --
> Daan
>



-- 

Andrija Panić
--------------------------------------
  http://admintweets.com
--------------------------------------

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message