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. The ACS management
log output you send was, what I think, later down the road where ACS gives
up trying to wait for the VR to come up. If you would capture the
job-executor in the management log from startCommand till the exception,
do you see anywhere a mention of ethnull? You might need to reed into the
DirectAgent executing the startCommand to find a clue. The thing is that I
only have experience with XS based environment so I cannot point you to
the exact output to look for. On XS, at least, it is
"[c.c.h.x.r.CitrixResourceBase] (DirectAgent-351:ctx-4a51bb9e) Created a
vif e4c362bd-764b-f651-dc9a-1abd5cb33c43 on 1"

Kind regards,
Joris van Lieshout

Schuberg Philis





On 30/05/14 10:48, "Andrija Panic" <andrija.pa...@gmail.com> wrote:

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

Reply via email to