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.hoogl...@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.pa...@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 < > jvanliesh...@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.pa...@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.hoogl...@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.ur...@citrix.com> wrote: > >> >> > 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, 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.hoogl...@gmail.com> > wrote: > >> >> >> > >> >> >>> 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 > >> >> >>> > >> >> >> > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> > >> >> >> Andrija Panić > >> >> >> -------------------------------------- > >> >> >> http://admintweets.com > >> >> >> -------------------------------------- > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Daan > >> >> > >> > > >> > > >> > > >> >-- > >> > > >> >Andrija Panić > >> >-------------------------------------- > >> > http://admintweets.com > >> >-------------------------------------- > >> > >> > > > > > > -- > > > > Andrija Panić > > -------------------------------------- > > http://admintweets.com > > -------------------------------------- > > > > -- > Daan > -- Andrija Panić -------------------------------------- http://admintweets.com --------------------------------------