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 --------------------------------------
