Re: Error - ACS v4.14 install on debian 9

[Pearl d'Silva]

Hi,

Based on the logs, it seems like the injectkeys.sh script is unable to find the 
mkisofs command, which is probably because mkisofs isn't available on Debian, 
you may install genisoimage and create a symlink:
apt-get install genisoimage
ln -s /usr/bin/genisoimage /usr/bin/mkisofs


Hope this helps.

Thanks,
Pearl


From: technologyrss.mail 
Sent: Sunday, July 18, 2021 10:19 AM
To: dev@cloudstack.apache.org 
Subject: Error - ACS v4.14 install on debian 9


Hi,

I am try to install ACS mgmt server v4.14 on Debian 9, installation done but I 
see some error. Please help me.

[cid:part1.EBB38C48.09BEC8FF@gmail.com]

Also can't access web url.

[cid:part2.91D1127D.E76DAEE7@gmail.com]

--

Thanks & Regards.

Support Admin

Facebook | Twitter | 
YouTube | 
LinkedIn

116/1 West Malibagh, D. I. T Road

Dhaka-1217, Bangladesh

Mob : +88 01716915504

Email : support.ad...@technologyrss.com

Web : www.technologyrss.com

 

Re: Error - ACS v4.14 install on debian 9

[technologyrss.mail]

Yes, Working.

I install this package before but not link.

Thank you so much!


---
Alamin


On 7/18/2021 11:14 AM, Pearl d'Silva wrote:

Hi,

Based on the logs, it seems like the injectkeys.sh script is unable to 
find the mkisofs command, which is probably because mkisofs isn't 
available on Debian, you may install genisoimage and create a symlink:

|apt-get install genisoimage|
|ln -s /usr/bin/genisoimage /usr/bin/mkisofs

|

Hope this helps.

Thanks,
Pearl



*From:* technologyrss.mail 
*Sent:* Sunday, July 18, 2021 10:19 AM
*To:* dev@cloudstack.apache.org 
*Subject:* Error - ACS v4.14 install on debian 9

*Hi,*

I am try to install ACS mgmt server v4.14 on Debian 9, installation 
done but I see some error. Please help me.


Also can't access web url.


--

*Thanks & Regards.*

*Support Admin*

Facebook | Twitter  | YouTube 
 | LinkedIn 



116/1 West Malibagh, D. I. T Road

Dhaka-1217, Bangladesh

*Mob :* +88 01716915504

*Email :* support.ad...@technologyrss.com 



*Web :* www.technologyrss.com 

Re: IPV6 in Isolated/VPC networks

[Hean Seng]

I think if doing this way ,  since you were to implement on peering ip
between vr and phsical router , then would need keep /56 or 48 at
Clodustack ?  We can only add /64 subnet to Cloudstack only (instead of
keep the /56 or 48 there).

I  saw other software provider do is adding /64 subnet to their system,
and  after that allocate subnet to the VM (from the previous added list).

May be considering the OSPF if really on this.  It really a nightmare for
maintaining 1000 or few thousand of BGP session.   You can imagine your
Cisco Router list of few thousand BGP session there.





On Fri, Jul 16, 2021 at 11:17 PM Wido den Hollander  wrote:

>
>
> Op 16-07-2021 om 16:42 schreef Hean Seng:
> > Hi Wido,
> >
> > In current setup,  each Cloudstack have own VR, so in this new  IPv6
> subnet
> > allocation , each VR (which have Frr) will need to have peering with ISP
> > router (and either BGP or Static Route) , and there is 1000 Acocunts,  it
> > will 1000 BGP session with ISP router ,  Am I right for this ? or I
> > understand wrong .
> >
>
> Yes, that is correct. A /56 would also be sufficient or a /60 which is
> enough to allocate a few /64 subnets.
>
> 1000 BGP connections isn't really a problem for a proper router at the
> ISP. OSPF(v3) would be better, but as I said that's poorly supported.
>
> The ISP could also install 1000 static routes, but that means that the
> ISP's router needs to have those configured.
>
> http://docs.frrouting.org/en/latest/ospf6d.html
> (While looking up this URL I see that Frr recently put in a lot of work
> in OSPFv3, seems better now)
>
> > I understand IPv6 is different then IPv4, and in IPv6 it suppose each
> > devices have own IP. It just how to realize in easy way.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jul 16, 2021 at 8:17 PM Wido den Hollander 
> wrote:
> >
> >>
> >>
> >> Op 16-07-2021 om 05:54 schreef Hean Seng:
> >>> Hi Wido,
> >>>
> >>> My initial thought is not like this,  it is the /48 at ISP router, and
> >> /64
> >>> subnet assign to AdvanceZoneVR,   AdvanceZoneVR responsible is
> >>> distribule IPv6 ip (from the assigned /64 sunet) to VM,  and not
> routing
> >>> the traffic,   in the VM that get the IPv6 IP will default route to ISP
> >>> router as gw.   It can may be a bridge over via Advancezone-VR.
> >>>
> >>
> >> How would you bridge this? That sounds like NAT?
> >>
> >> IPv6 is meant to be routed. Not to be translated or bridged in any way.
> >>
> >> The way a made the drawing is exactly how IPv6 should work in a VPC
> >> environment.
> >>
> >> Traffic flows through the VR where it can do firewalling of the traffic.
> >>
> >>> However, If do as the way described in the drawing, then i suppose will
> >> be
> >>> another kind of virtual router going to introduce , to get hold the /48
> >> in
> >>> this virtual router right ?
> >>>
> >>
> >> It can be the same VR. But keep in mind that IPv6 != IPv4.
> >>
> >> The VR will get Frr as a new daemon which can talk BGP with the upper
> >> network to route traffic.
> >>
> >>> After this,  The Advance Zone, NAT's  VR will peer with this new IPv6
> VR
> >>> for getting the IPv6 /64 prefix ?
> >>>
> >>
> >> IPv4 will be behind NAT, but IPv6 will not be behind NAT.
> >>
> >>> If do in this way, then I guess  you just only need Static route, with
> >>> peering ip both end  as one /48 can have a lot of /64 on it.  And
> >> hardware
> >>> budgeting for new IPv6-VR will become very important, as all traffic
> will
> >>> need to pass over it .
> >>>
> >>
> >> Routing or NAT is the same for the VR. You don't need a very beefy VR
> >> for this.
> >>
> >>> It will be like
> >>>
> >>> ISP Router  -- >  (new IPV6-VR )  > AdvanceZone-VR > VM
> >>>
> >>> Relationship of (new IPv6 VR) and AdvanceZone-VR , may be considering
> on
> >>> OSPF instead of  BGP , otherwise few thousand of AdvanceZone-VR wil
> have
> >>> few thousand of BGP session. on new-IPv6-VR
> >>>
> >>> Also, I suppose we cannot do ISP router. -->. Advancezone VR direct,
>  ,
> >>> otherwise ISP router will be full of /64 prefix route either on BGP(
> Many
> >>> BGP Session) , or  Many Static route .   If few thousand account, ti
> will
> >>> be few thousand of BGP session with ISP router or few thousand static
> >> route
> >>> which  is not possible .
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Jul 15, 2021 at 10:47 PM Wido den Hollander 
> >> wrote:
> >>>
>  But you still need routing. See the attached PNG (and draw.io XML).
> 
>  You need to route the /48 subnet TO the VR which can then route it to
>  the Virtual Networks behind the VR.
> 
>  There is no other way then routing with either BGP or a Static route.
> 
>  Wido
> 
>  Op 15-07-2021 om 12:39 schreef Hean Seng:
> > Or explain like this :
> >
> > 1) Cloudstack generate list of /64 subnet from /48 that Network admin
> > assigned to Cloudstack
> > 2) Cloudsack allocated the subnet (that generated from step1) to
> >> Virtual