Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Wesley Peng]

Andrija Panic wrote:

http://docs.cloudstack.apache.org/en/latest/upgrading/upgrade/upgrade-4.13.html#time-zone-requirements


handled in the Upgrade docs - exactly the same..



[OT] is there a cloudstack private IAAS deployment solution? not that 
large scale, most for storage. if there is the commercial solution, we 
can pay for it.


Thanks.

Re: Unable to start agent: Failed to get private nic name

[Practical XenServer]

FYI: There are three different interfaces configured/enabled/functioning on
this host:

1 active-passive bonded interface [172.16.0.1/24] consisting of two slaves
(p1p3 & p1p4).
2 physical interfaces (p1p1 [172.16.1.3/25] & p1p2 [172.16.1.131/25]).

During the /usr/bin/cloudstack-setup process, *when prompted "Please choose
which network used to create VM:[bond0]*, it doesn't seem to make any
difference what answer I provide - bond0, p1p1, 172.16.1.3, p1p2, or
172.16.1.131. The CloudStack agent fails to start.

Ideas? Suggestions?

TIA,
Eric P.

On Wed, Jun 3, 2020 at 2:40 PM Practical XenServer <
practicalxenser...@gmail.com> wrote:

> Thanks, Fariborz.
>
> But you're pointing me to the same page that I referenced in my original
> message i.e.,
>
> /en/latest/installguide/hypervisor/kvm.html = /en/4.6/hypervisor/kvm.html
>
> Do you have any *new* information to share?
>
> TIA,
> Eric P.
>
> On Wed, Jun 3, 2020 at 2:27 PM Fariborz Navidan 
> wrote:
>
>> Hello,
>>
>> This happens when bridges are not configured on the host and there is no
>> private ip assigned to your nic. Please check your bridge config as
>> mentions in installation documentation here:
>>
>> http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.6/hypervisor/kvm.html
>>
>> On Thu, Jun 4, 2020 at 1:51 AM Practical XenServer <
>> practicalxenser...@gmail.com> wrote:
>>
>> > Hello!
>> >
>> > I've been following the installation instructions for installing the
>> > CloudStack agent on a CentOS-7 KVM host
>> > <
>> >
>> http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#install-and-configure-the-agent
>> > >:
>> > But I can't get the cloudstack-agent to start. e.g., From the end of
>> > /var/log/cloudstack/agent/agent.log:
>> >
>> > > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service: main process
>> > exited, code=exited, status=66/n/a
>> > > Jun  3 17:06:48 vmh-1 systemd: Unit cloudstack-agent.service entered
>> > failed state.
>> > > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service failed.
>> >
>> > I've collected all of the evidence that seems relevant
>> >  (e.g., interface configuration &
>> status;
>> > the configuration & status of libvirtd; etc) and put it in Pastebin.
>> >
>> > Would somebody please help me fix my installation of cloudstack-agent?
>> >
>> > TIA,
>> > Eric Pretorious
>> > Portland, Oregon
>> >
>>
>

Re: Unable to start agent: Failed to get private nic name

[Practical XenServer]

Thanks, Fariborz.

But you're pointing me to the same page that I referenced in my original
message i.e.,

/en/latest/installguide/hypervisor/kvm.html = /en/4.6/hypervisor/kvm.html

Do you have any *new* information to share?

TIA,
Eric P.

On Wed, Jun 3, 2020 at 2:27 PM Fariborz Navidan 
wrote:

> Hello,
>
> This happens when bridges are not configured on the host and there is no
> private ip assigned to your nic. Please check your bridge config as
> mentions in installation documentation here:
>
> http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.6/hypervisor/kvm.html
>
> On Thu, Jun 4, 2020 at 1:51 AM Practical XenServer <
> practicalxenser...@gmail.com> wrote:
>
> > Hello!
> >
> > I've been following the installation instructions for installing the
> > CloudStack agent on a CentOS-7 KVM host
> > <
> >
> http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#install-and-configure-the-agent
> > >:
> > But I can't get the cloudstack-agent to start. e.g., From the end of
> > /var/log/cloudstack/agent/agent.log:
> >
> > > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service: main process
> > exited, code=exited, status=66/n/a
> > > Jun  3 17:06:48 vmh-1 systemd: Unit cloudstack-agent.service entered
> > failed state.
> > > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service failed.
> >
> > I've collected all of the evidence that seems relevant
> >  (e.g., interface configuration & status;
> > the configuration & status of libvirtd; etc) and put it in Pastebin.
> >
> > Would somebody please help me fix my installation of cloudstack-agent?
> >
> > TIA,
> > Eric Pretorious
> > Portland, Oregon
> >
>

Re: Unable to start agent: Failed to get private nic name

[Fariborz Navidan]

Hello,

This happens when bridges are not configured on the host and there is no
private ip assigned to your nic. Please check your bridge config as
mentions in installation documentation here:
http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.6/hypervisor/kvm.html

On Thu, Jun 4, 2020 at 1:51 AM Practical XenServer <
practicalxenser...@gmail.com> wrote:

> Hello!
>
> I've been following the installation instructions for installing the
> CloudStack agent on a CentOS-7 KVM host
> <
> http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#install-and-configure-the-agent
> >:
> But I can't get the cloudstack-agent to start. e.g., From the end of
> /var/log/cloudstack/agent/agent.log:
>
> > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service: main process
> exited, code=exited, status=66/n/a
> > Jun  3 17:06:48 vmh-1 systemd: Unit cloudstack-agent.service entered
> failed state.
> > Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service failed.
>
> I've collected all of the evidence that seems relevant
>  (e.g., interface configuration & status;
> the configuration & status of libvirtd; etc) and put it in Pastebin.
>
> Would somebody please help me fix my installation of cloudstack-agent?
>
> TIA,
> Eric Pretorious
> Portland, Oregon
>

Unable to start agent: Failed to get private nic name

[Practical XenServer]

Hello!

I've been following the installation instructions for installing the
CloudStack agent on a CentOS-7 KVM host
:
But I can't get the cloudstack-agent to start. e.g., From the end of
/var/log/cloudstack/agent/agent.log:

> Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service: main process
exited, code=exited, status=66/n/a
> Jun  3 17:06:48 vmh-1 systemd: Unit cloudstack-agent.service entered
failed state.
> Jun  3 17:06:48 vmh-1 systemd: cloudstack-agent.service failed.

I've collected all of the evidence that seems relevant
 (e.g., interface configuration & status;
the configuration & status of libvirtd; etc) and put it in Pastebin.

Would somebody please help me fix my installation of cloudstack-agent?

TIA,
Eric Pretorious
Portland, Oregon

Using public IP range for shared guest network in advanced zone

[Fariborz Navidan]

Hello,

I am running CS 4.14. I have created an advanced zone without security
groups enabled. It forced me to create public IP range which is the only
available IP block in this rack assigned by datacenter. Now I'm not able to
create shared guest network with that IP range. Is it somehow possible to
share this public IP range with VMs? If not, is it possible to enable
security group on an existing zone or I should re-create the zone?

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Andrija Panic]

http://docs.cloudstack.apache.org/en/latest/upgrading/upgrade/upgrade-4.13.html#time-zone-requirements


handled in the Upgrade docs - exactly the same..

Best,
Andrija

On Wed, 3 Jun 2020 at 14:39, Gabriel Beims Bräscher 
wrote:

> I know that the VOTE has passed, but I would like to add an answer
> addressing the Liridon issue regarding DB  failing to start due to time
> zone.
>
> In such case, CloudStack fails to connect DB and therefore it does not
> start.
>
> Message  regarding time zone value:
>
> Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The
> > server time zone value 'CEST' is unrecognized or represents more than one
> > time zone. You must configure either the server or JDBC driver (via the
> > 'serverTimezone' configuration property) to use a more specifc time zone
> > value if you want to utilize time zone support.
> > at
> >
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> > Method)
> > at
> >
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> > at
> >
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> >
>
> To fix it is just update *db.cloud.url.params* (adding =UTC)
> and *db.usage.url.params* (adding serverTimezone=UTC) on
> */etc/cloudstack/management/db.properties*.
>
> Updated values on those configurations are:
>
> > *db.cloud.url.params=*
> >
> prepStmtCacheSize=517=true=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'=UTC
> > ...
> > *db.usage.url.params=*serverTimezone=UTC
> >
>
> Note that this should not happen during the upgrade if accepting the
> changes on */etc/cloudstack/management/db.properties* (press yes when asked
> during upgrade); however, if the file has not been changed, then the above
> steps could help.
>
> Cheers,
> Gabriel.
>
> Em qua., 27 de mai. de 2020 às 15:43, Riepl, Gregor (SWISS TXT) <
> gregor.ri...@swisstxt.ch> escreveu:
>
> > Thank you, Andrija!
> >
> > We will keep that in mind when we upgrade to 6.7.
> > 
> > From: Andrija Panic 
> > Sent: 20 May 2020 23:02
> > To: users 
> > Cc: dev 
> > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
> >
> > @gregor - the legacy should be fine with UEFI (what I had run on some of
> my
> > laptops); UEFI is not a problem, happens with 4.13 also, any VirtualBox
> OVA
> > file will cause the issue
> >
> > ###
> > To conclude the ISSUE, based on my few hour testing today:
> >
> > - happens when you deliberately use VirtualBox OVA template with vSphere
> > (who and why would do that, is another topic..), in ACS 4.13.x and
> > 4.14/master
> >
> > ...out of which...:
> >
> > - does NOT happen with vCenter 6.0 and 6.5 (confirmed by Daan/Bobby),
> > proper OVF parsing takes place and an error message is generated in ACS
> > logs
> > - NOT tested:   6.7 / 6.7 U1xxx / 6.7 U2xxx (i.e. not tested with any
> > variant < 6.7 U3)
> > - issues happen with vCenter 6.7 U3  / U3a / U3b / U3f - these were
> > explicitly tested by me and some vCenter services would crash (though
> still
> > appearing as running) - the problem is solved by restarting (most?)
> > services - namely "VMware afd Service" will trigger other services to
> > restart (dependency) and after a while vCenter is UP again (I could not
> > find which exact service (single one) might be the issue)
> > - Worth mentioning this was observed on vCenter on Windows Server, not
> the
> > VCSA appliance
> >
> > -  seems FINE - NO ISSUES with vCenter 6.7 U3g (the latest 6.7 U3
> variants
> > at the moment - build 16046470 from 28.04.2020) and the VM deployment
> fails
> > gracefully with a proper error message of not being able to create SPEC
> > file based on the (bad) OVF.
> > 
> >
> > Since the issue is solved in the (current) latest vSphere 6.7 U3g
> variant,
> > I will make sure to have the proper warning message on both 4.13.1 and
> > 4.14.0.0 Release notes documentation (4.13 is when we started supporting
> > vSphere 6.7 and the same issue present here)
> >
> > I'll proceed tomorrow with releasing 4.14 based on the voting done so
> far.
> >
> > Thanks
> >
> > On Wed, 20 May 2020 at 22:09, Marcus  wrote:
> >
> > > I would say, if it is proven that this happens with existing released
> > > CloudStack versions, with or without the UEFI feature, against a
> specific
> > > VMware release with a specific broken template, then it becomes an
> > > environment issue and shouldn't block the release.  In this case it
> would
> > > not matter if we tried to revert the feature, or if we did or did not
> > > release 4.14, the users who would hit this would be hitting this now in
> > > live environments, with the released versions of CloudStack.
> > >
> > > To 

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Gabriel Beims Bräscher]

I know that the VOTE has passed, but I would like to add an answer
addressing the Liridon issue regarding DB  failing to start due to time
zone.

In such case, CloudStack fails to connect DB and therefore it does not
start.

Message  regarding time zone value:

Caused by: com.mysql.cj.exceptions.InvalidConnectionAttributeException: The
> server time zone value 'CEST' is unrecognized or represents more than one
> time zone. You must configure either the server or JDBC driver (via the
> 'serverTimezone' configuration property) to use a more specifc time zone
> value if you want to utilize time zone support.
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>

To fix it is just update *db.cloud.url.params* (adding =UTC)
and *db.usage.url.params* (adding serverTimezone=UTC) on
*/etc/cloudstack/management/db.properties*.

Updated values on those configurations are:

> *db.cloud.url.params=*
> prepStmtCacheSize=517=true=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'=UTC
> ...
> *db.usage.url.params=*serverTimezone=UTC
>

Note that this should not happen during the upgrade if accepting the
changes on */etc/cloudstack/management/db.properties* (press yes when asked
during upgrade); however, if the file has not been changed, then the above
steps could help.

Cheers,
Gabriel.

Em qua., 27 de mai. de 2020 às 15:43, Riepl, Gregor (SWISS TXT) <
gregor.ri...@swisstxt.ch> escreveu:

> Thank you, Andrija!
>
> We will keep that in mind when we upgrade to 6.7.
> 
> From: Andrija Panic 
> Sent: 20 May 2020 23:02
> To: users 
> Cc: dev 
> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
>
> @gregor - the legacy should be fine with UEFI (what I had run on some of my
> laptops); UEFI is not a problem, happens with 4.13 also, any VirtualBox OVA
> file will cause the issue
>
> ###
> To conclude the ISSUE, based on my few hour testing today:
>
> - happens when you deliberately use VirtualBox OVA template with vSphere
> (who and why would do that, is another topic..), in ACS 4.13.x and
> 4.14/master
>
> ...out of which...:
>
> - does NOT happen with vCenter 6.0 and 6.5 (confirmed by Daan/Bobby),
> proper OVF parsing takes place and an error message is generated in ACS
> logs
> - NOT tested:   6.7 / 6.7 U1xxx / 6.7 U2xxx (i.e. not tested with any
> variant < 6.7 U3)
> - issues happen with vCenter 6.7 U3  / U3a / U3b / U3f - these were
> explicitly tested by me and some vCenter services would crash (though still
> appearing as running) - the problem is solved by restarting (most?)
> services - namely "VMware afd Service" will trigger other services to
> restart (dependency) and after a while vCenter is UP again (I could not
> find which exact service (single one) might be the issue)
> - Worth mentioning this was observed on vCenter on Windows Server, not the
> VCSA appliance
>
> -  seems FINE - NO ISSUES with vCenter 6.7 U3g (the latest 6.7 U3 variants
> at the moment - build 16046470 from 28.04.2020) and the VM deployment fails
> gracefully with a proper error message of not being able to create SPEC
> file based on the (bad) OVF.
> 
>
> Since the issue is solved in the (current) latest vSphere 6.7 U3g variant,
> I will make sure to have the proper warning message on both 4.13.1 and
> 4.14.0.0 Release notes documentation (4.13 is when we started supporting
> vSphere 6.7 and the same issue present here)
>
> I'll proceed tomorrow with releasing 4.14 based on the voting done so far.
>
> Thanks
>
> On Wed, 20 May 2020 at 22:09, Marcus  wrote:
>
> > I would say, if it is proven that this happens with existing released
> > CloudStack versions, with or without the UEFI feature, against a specific
> > VMware release with a specific broken template, then it becomes an
> > environment issue and shouldn't block the release.  In this case it would
> > not matter if we tried to revert the feature, or if we did or did not
> > release 4.14, the users who would hit this would be hitting this now in
> > live environments, with the released versions of CloudStack.
> >
> > To be clear, I'm not 100% certain this is exactly what Bobby was saying,
> > but if this is the case then I think it should not block us.
> >
> > On Wed, May 20, 2020 at 1:00 AM Riepl, Gregor (SWISS TXT) <
> > gregor.ri...@swisstxt.ch> wrote:
> >
> > > Hi everyone
> > >
> > > Sorry for the late response, but I have a few concerns:
> > >
> > >
> > >   *   As Bobby stated, this bug seems to only occur with VMware 6.7+,
> and
> > > it sounds to me like they should 

Re: [DISCUSS] New default template

[Andrija Panic]

Whatever is a choosen as the new one, needs to be compatible with ALL the
current hypervisor we support (i. e. VMware 6.0 and up, XenServer 7.0 and
up and KVM of various flavours).
So that needs to be taken into consideration when speaking about exotic
OS-es or even the newest ones (Ubuntu 20/CentOS 8) to find a proper OS
mappings on hypervisor side that will allow it to run normally.



On Wed, 3 Jun 2020, 12:21 ,  wrote:

> Hi,
>
> I'd like to restate my previous stance on this which is - if not to have
> a proper "market place" of trusted and tested templates - at least to
> cover the popular ones.
> The basics imho would be CentOS and Ubuntu, with this we cover 99% of
> the user requirements.
> I'd propose to go with the latest and greatest of both, Ubuntu 20.04 and
> CentOS8 respectively (supported 2029).
> I can repurpose the current build machine for openvm.eu and "donate" it
> to the project so it's not a "third party" any more.
>
> my 2 pence
>
> On 2020-06-03 08:58, Abhishek Kumar wrote:
> > Hi all,
> >
> > I would like to hear everyone's opinion on a new default template in
> > CloudStack.
> > Currently, we are using CentOS 5.x for different hypervisors but it is
> > quite old(already completed its support life) and either the support
> > for it has been removed
> > (https://github.com/xcp-ng/xcp/wiki/Guest-System-Support) or in legacy
> > (
> https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software=1=272=448=1_interval=10=Partner=Asc=16
> )
> > in different hypervisors.
> > Therefore, I think it is time now to move to a newer OS template. In
> > my understanding CentOS7 is the minimum viable choice if we are
> > continuing with CentOS. This can be the preferred choice as we already
> > have tested templates for it on different hypervisors and it has 4
> > years left in its cycle.
> >
> > We can also explore Ubuntu’s cloud-images of 20.04. And if we want to
> > go with something very light-weight we can think about something like
> > Alpine Linux.
> >
> > Please have your say. Also, do you think this can be included in 4.15
> > itself so we can have a proper default template for something like
> > XCP-ng 8.x which doesn't support CentOS 5 (and PV VMs)?
> >
> > Regards,
> > Abhishek
> >
> >
> > abhishek.ku...@shapeblue.com
> > www.shapeblue.com
> > 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> > @shapeblue
>

Re: [DISCUSS] New default template

[nux]

Hi,

I'd like to restate my previous stance on this which is - if not to have 
a proper "market place" of trusted and tested templates - at least to 
cover the popular ones.
The basics imho would be CentOS and Ubuntu, with this we cover 99% of 
the user requirements.
I'd propose to go with the latest and greatest of both, Ubuntu 20.04 and 
CentOS8 respectively (supported 2029).
I can repurpose the current build machine for openvm.eu and "donate" it 
to the project so it's not a "third party" any more.


my 2 pence

On 2020-06-03 08:58, Abhishek Kumar wrote:

Hi all,

I would like to hear everyone's opinion on a new default template in 
CloudStack.

Currently, we are using CentOS 5.x for different hypervisors but it is
quite old(already completed its support life) and either the support
for it has been removed
(https://github.com/xcp-ng/xcp/wiki/Guest-System-Support) or in legacy
(https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software=1=272=448=1_interval=10=Partner=Asc=16)
in different hypervisors.
Therefore, I think it is time now to move to a newer OS template. In
my understanding CentOS7 is the minimum viable choice if we are
continuing with CentOS. This can be the preferred choice as we already
have tested templates for it on different hypervisors and it has 4
years left in its cycle.

We can also explore Ubuntu’s cloud-images of 20.04. And if we want to
go with something very light-weight we can think about something like
Alpine Linux.

Please have your say. Also, do you think this can be included in 4.15
itself so we can have a proper default template for something like
XCP-ng 8.x which doesn't support CentOS 5 (and PV VMs)?

Regards,
Abhishek


abhishek.ku...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue

Re: [DISCUSS] New default template

[Rohit Yadav]

We've discussed this in the past:
https://markmail.org/message/lp5pjholfxrqhful
https://markmail.org/message/mkoasohxr5vwyt3l

We probably want both CentOS and Ubuntu based built-in (or default user) 
templates, and some people may even prefer Debian, Fedora or even FreeBSD.
I think it would simpler if the built-in template is a single template and 
based on DistroWatch [1] it seems a Debian based OS may be more preferable for 
most users.
Therefore, either a LTS version of Ubuntu (say Ubuntu 20.04) or even Debian is 
preferable. The cons of this decision would be to test and fix many smoke tests 
and component tests.

If we prefer Debian (latest LTS), we can actually make the systemvmtemplate 
cloud-init enabled and use it both as the template for system vms but also 
guest VMs. For every release, we won't need to maintain two separate templates 
(a systemvmtemplate and a built-in template) and revisit this issue again in 
say next 5 years. A Debian (latest LTS) based built-in template may even serve 
for the CKS feature (so if this is do-able and done right, we'll solve the 
template issue for systemvms, built-in template and CKS).

To summarise:

  *   A CentOS7 based (cloud-init enabled) built-in template would be easiest 
thing to do (in terms of effort and testing); we already have the packer script 
that we needs an update - 
https://github.com/apache/cloudstack/tree/master/tools/appliance/builtin
  *   An Ubuntu 20.04 current/LTS based (cloud-init) template would be 
something that most users would want; but adds effort on fixing integration 
tests
  *   A Debian LTS based (cloud-init) template would add effort on fixing 
integration tests but would serve most of our requirements which I think are:
 *   Users prefer a Debian/Ubuntu based guest OS
 *   The template can be cloud-init enabled to work out of box for SSH 
acccess
 *   We already have the packer script 
(https://github.com/apache/cloudstack/tree/master/tools/appliance/systemvmtemplate)
 that we can extend to build a single template to serve for systemvmtemplate, 
built-in template and template for CKS as:
*   Replace and refactor cloud-early-config with a cloud-init equivalent
*   Install hypervisor-specific guest tools (we already do this for 
systemvmtemplate)
*   Remove noncommon packages and instead either build that as a docker 
image (tar file) or deb files bundled in systemvm.iso (such as JRE, strongswan, 
docker etc)
  *   Debian templates are big in size, to keep the template size very small 
and further improve how systemvmtemplates are seeded, we can explore Alpine 
Linux (or similar?)

[1] https://distrowatch.com/dwres.php?resource=popularity


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Abhishek Kumar 
Sent: Wednesday, June 3, 2020 13:28
To: d...@cloudstack.apache.org 
Cc: users@cloudstack.apache.org 
Subject: [DISCUSS] New default template

Hi all,

I would like to hear everyone's opinion on a new default template in CloudStack.
Currently, we are using CentOS 5.x for different hypervisors but it is quite 
old(already completed its support life) and either the support for it has been 
removed (https://github.com/xcp-ng/xcp/wiki/Guest-System-Support) or in legacy 
(https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software=1=272=448=1_interval=10=Partner=Asc=16)
 in different hypervisors.
Therefore, I think it is time now to move to a newer OS template. In my 
understanding CentOS7 is the minimum viable choice if we are continuing with 
CentOS. This can be the preferred choice as we already have tested templates 
for it on different hypervisors and it has 4 years left in its cycle.

We can also explore Ubuntu’s cloud-images of 20.04. And if we want to go with 
something very light-weight we can think about something like Alpine Linux.

Please have your say. Also, do you think this can be included in 4.15 itself so 
we can have a proper default template for something like XCP-ng 8.x which 
doesn't support CentOS 5 (and PV VMs)?

Regards,
Abhishek


abhishek.ku...@shapeblue.com
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue




rohit.ya...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

[DISCUSS] New default template

[Abhishek Kumar]

Hi all,

I would like to hear everyone's opinion on a new default template in CloudStack.
Currently, we are using CentOS 5.x for different hypervisors but it is quite 
old(already completed its support life) and either the support for it has been 
removed (https://github.com/xcp-ng/xcp/wiki/Guest-System-Support) or in legacy 
(https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software=1=272=448=1_interval=10=Partner=Asc=16)
 in different hypervisors.
Therefore, I think it is time now to move to a newer OS template. In my 
understanding CentOS7 is the minimum viable choice if we are continuing with 
CentOS. This can be the preferred choice as we already have tested templates 
for it on different hypervisors and it has 4 years left in its cycle.

We can also explore Ubuntu’s cloud-images of 20.04. And if we want to go with 
something very light-weight we can think about something like Alpine Linux.

Please have your say. Also, do you think this can be included in 4.15 itself so 
we can have a proper default template for something like XCP-ng 8.x which 
doesn't support CentOS 5 (and PV VMs)?

Regards,
Abhishek


abhishek.ku...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

OVS related questions

[Po Dragonwarrior]

Hi all, 

I am trying oenvswitch with ACS and I have some questions:

1. The “OpenVswitch Network Example” section 
inhttp://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#kvm-installation-overview
 
http://docs.cloudstack.apache.org/en/latest/installguide/hypervisor/kvm.html#kvm-installation-overview>
 refers to Basic networking mode or Advanced?
2. It says that "at least two bridges: public and private.” should exist. Does 
private equals to “guest” network in ACS?
3. During the Zone addition should I have to enter the vlan vlaues for Public 
(=200) and Pod (=100) ?
4. Again, on the Web UI during the Guest networking tab should I declare a 
range of VLANs (e.g. 1000-1100), or I have to declare the 300 value?


best,
Po