Re: Cloudstack Upgrade Filed

[hanumant borwandkar]

Hi,

Issue resolved and able to upgrade from 4.11.3 to  4.13.1.0-1 with the
reading fix mentioned in the post
*https://github.com/apache/cloudstack/issues/3221
* able to get going
schema restore.
and the following commands execution on mariadb centos 7 *
https://www.mail-archive.com/users@cloudstack.apache.org/msg27985.html
. *

delete from guest_os_hypervisor where guest_os_id >= 277;
delete from guest_os where id >= 277;
SET FOREIGN_KEY_CHECKS=0;
drop table direct_download_certificate;
drop table vpc_offering_details;
SET FOREIGN_KEY_CHECKS=1;
alter table data_center drop column sort_key;
alter table vpc_offerings drop column sort_key;
alter table disk_offering add column domain_id int(32) not null;
alter table service_offering_details add constraint
uk_service_offering_id_name unique (id);
alter table network_offering_details DROP COLUMN `display`;

Thanks,
Hanumant B




On Fri, May 15, 2020 at 12:28 PM hanumant borwandkar <
hanumant.borwand...@gmail.com> wrote:

> Hi,
>
> Thanks for the replies i will try to reproduce errors again may be i am
> doing anything wrong., But I referring latest documentation relating
> upgrade from 4.11.x to 4.13
>
> Not sure why I am getting access denied & need of  super user previledges
> error as I am upgrading with root user and yum upgrade command and using
> mentioned yum repo in documentation
>
> As there are two management servers and I am using mariadb 5.5.65 from
> centos7 repo in master slave scenario.
>
> Both the  management server are upgraded from 4.11.0 to 4.11.3 successful
> previously some months ago.
>
> Regards,
> Hanumant B
>
> On Fri, May 15, 2020, 11:51 Thomas Joseph  wrote:
>
>> Hello Hanumant
>>
>> Are you using the correct user for running the related scripts?
>>
>> *020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
>> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied;
>> you need (at least one of) the SUPER privilege(s) for this
>> operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
>> (main:null) (logid:) Unable to execute upgrade
>> scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
>> denied; you need (at least one of) the SUPER privilege(s) for this
>> operation*
>>
>> With regards
>> Thomas Joseph
>>
>> On Fri, 15 May 2020, 5:20 am Luis, 
>> wrote:
>>
>> > Hi. What lines did you use for the upgrade?
>> >
>> > Sent from Yahoo Mail on Android
>> >
>> >   On Thu, May 14, 2020 at 6:43 PM, hanumant borwandkar<
>> > hanumant.borwand...@gmail.com> wrote:   HI,
>> >
>> > Trying to upgrade cloudstack 4.11.3 to 4.13 latest but unable get
>> success
>> > also tried to upgrade to 4.14-RC3 test build both time got same error as
>> > follows.
>> >
>> > CentOS Linux release 7.6.1810 (Core)
>> >
>> >
>> > ERROR
>> > 2
>> >
>> >
>> > *020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
>> denied;
>> > you need (at least one of) the SUPER privilege(s) for this
>> > operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
>> > (main:null) (logid:) Unable to execute upgrade
>> > scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
>> > denied; you need (at least one of) the SUPER privilege(s) for this
>> > operation*
>> >
>> >
>> > logs
>> > 2020-05-15 00:12:41,329 DEBUG [c.c.u.d.VersionDaoImpl] (main:null)
>> (logid:)
>> > Checking to see if the database is at a version before it was the
>> version
>> > table is created
>> > 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
>> > (logid:) DB version = 4.11.3.0 Code Version = 4.13.1.0
>> > 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
>> > (logid:) Database upgrade must be performed from 4.11.3.0 to 4.13.1.0
>> > 2020-05-15 00:12:41,392 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
>> > (logid:) Running upgrade Upgrade41120to41200 to upgrade from
>> > 4.11.2.0-4.12.0.0 to 4.12.0.0
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- Licensed to the Apache Software Foundation (ASF) under one
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- or more contributor license agreements.  See the NOTICE file
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- distributed with this work for additional information
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- regarding copyright ownership.  The ASF licenses this file
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- to you under the Apache License, Version 2.0 (the
>> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null)
>> (logid:)
>> > -- "License"); you may not use this file 

Re: Hello and first doubts!

[info]

Thank you very much Simon for your kind answer. Can you explain me 
little more about it? I put my questions below your answers


On 15/05/2020 16:13, Simon Weller wrote:

Welcome Augusto!

I'll do my best to answer your questions and I'm sure others will chime in as 
well.


   1.  CloudStack is designed to scale to massive levels and supports various 
levels of availability. Typically, if you are going to be building out services 
in different geographic areas, you'd separate those into CloudStack Regions.  A 
region is designed to be completely self-contained, with no dependencies on 
other regions. Please see this URL for more detail on this - 
https://docs.cloudstack.apache.org/en/latest/conceptsandterminology/concepts.html#cloudstack-terminology


Then each region needs a separate management server as I read, and the 
zones are like "datacenters". Then to manage each region must I change 
from management server admin website? I mean open different url/ip in 
browser?. Becouse if not it seems that the region are fully separated 
ones from the others.


For example, can I move VM from region to region by using the management 
web tool?




   2.  AWS and other vendors do offer some bare metal services. As long as you 
have direct access to the underlying server hardware, you could definitely 
utilize them as CloudStack Hosts. CloudStack does support a number of 
hypervisors, either directly (as in the case with KVM), or via other management 
systems (such as VMWare with vSphere). Think of CloudStack as an orchestrator 
or orchestrators.


Then, if I understand you well, for now we can only use phisical server 
hardware (bare metal) as hosts?. Or do you meant that we can use KVM VMs 
as hosts?


Obviously I am trying to find the most cheap servers to install as 
hosts, and I think that vmware option to use AWS virtual resources as 
nodes its a great resource. You can build a "worldwide datacenter 
networks" by using the AWS locations.


What hypervisor do you suggest? Currently I use KVM with virtualizor, 
but I am open to choose another (free option).




   3.  CloudStack networking can be deploying in a number of ways. At the most 
simplistic level, you can deploy hosts and use host based security groups for 
separation with little to no complexity on the underlay network.  You can also 
utilize advanced networking and separate Virtual Private Clouds (VPCs) via 
VLANs, VXLANs or other tunnel protocols depending on what the underlining 
hypervisor supports.


Understood.



CloudStack is in use by large cloud providers and huge corporations world wide 
and it built to be extremely robust, while still providing the flexibility that 
different entities require. We have a large community and a lot of vendor 
integrations allowing the cloud operator to mix and match technologies that 
better suit their needs.


Thank you for your help!



-Si




From: i...@defendhosting.com 
Sent: Friday, May 15, 2020 7:05 AM
To: users@cloudstack.apache.org 
Subject: Hello and first doubts!


Hello,

My name is Augusto and I am new here. Hello to all. Glad to be here.

I am new in cloudstack and I have some doubts that may be can be
answered here. I already provide server and vps service, but I would
like to provide cloud service with cloudstack in several locations.

First of all, I am sorry because my cloudstack knowledge is near to
null. I plan to start now, and for that reason I have these doubs:

1).- The master and the hosts must be in same datacenter?. I mean, if I
install a master in europe, can I manage the hosts in Europe, USA,
Canada and other locations?. For example using a hetzner server for
master and ovh or sys for hosts.

2).- I saw some videos about vmware, indicating that it is possible to
use AWS infraestructure to deploy hosts and use their infraestructure to
growup creating several "virtual datacenters". That can be done with
cloudstack? (or with other major clouds)

3).- If hosts are deployed in same datacenter, for example OVH, Is there
additional tasks to acomplish regarding the network? I mean, creating
for example an vRack or it is not necessary and cloudstack will manage all?

Thank you for your

--

█ DEFEND HOSTING - www.defendhosting.com - A 
Company You Can Trust
█ Shared Hosting | VPS | Dedicated Servers | SEO | PBX, CRM and SEO Servers
█ USA/EU Locations | Fast Network/Server Backbone Connection
█ Best Value For Your Money | Outstanding Uptime | Customer Tailored
Support | Money-Back Guarantee

--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus


--

█ DEFEND HOSTING - www.defendhosting.com - A Company You Can Trust
█ Shared Hosting | VPS | Dedicated Servers | SEO | PBX, CRM and SEO Servers
█ USA/EU Locations | Fast Network/Server Backbone Connection
█ Best Value For Your Money | Outstanding Uptime | Customer Tailored 
Support | Money-Back Guarantee


--

Re: CloudStack 4.13.1.0 download

[Luis Martinez]

Thank you for the information.

On 5/15/2020 3:01 PM, Andrija Panic wrote:

Hi Luis,

there is a big blue note as following - pay attention to the last part:

The Apache CloudStack official releases are source code. As such there are
no ‘official’ binaries available. The full installation guide describes how
to take the source release and generate RPMs and and yum repository. This
guide attempts to keep things as simple as possible, and thus we are using
one of the community-provided yum repositories.
**Furthermore, this example assumes a 4.11 Cloudstack install - substitute
versions as needed.**

On Fri, 15 May 2020 at 20:08, Luis Martinez 
wrote:


Hi Group

I am reading the documentation for 4.13.1.0 and the repository is
pointing to 4.11, is this correct?


http://docs.cloudstack.apache.org/en/4.13.1.0/quickinstallationguide/qig.html

[cloudstack]
name=cloudstack
baseurl=http://download.cloudstack.org/centos/7/4.11/
enabled=1
gpgcheck=0 I also tried to change it to 4.13.13.1.0 but it's not working
another question, do I need to use systemvmtemplate-4.11.3-kvm.qcow2.bz2
with 4.13.1.0 or can I use a recent qcow file? thank you for yout help.

Re: CloudStack 4.13.1.0 download

[Andrija Panic]

Hi Luis,

there is a big blue note as following - pay attention to the last part:

The Apache CloudStack official releases are source code. As such there are
no ‘official’ binaries available. The full installation guide describes how
to take the source release and generate RPMs and and yum repository. This
guide attempts to keep things as simple as possible, and thus we are using
one of the community-provided yum repositories.
**Furthermore, this example assumes a 4.11 Cloudstack install - substitute
versions as needed.**

On Fri, 15 May 2020 at 20:08, Luis Martinez 
wrote:

> Hi Group
>
> I am reading the documentation for 4.13.1.0 and the repository is
> pointing to 4.11, is this correct?
>
>
> http://docs.cloudstack.apache.org/en/4.13.1.0/quickinstallationguide/qig.html
>
> [cloudstack]
> name=cloudstack
> baseurl=http://download.cloudstack.org/centos/7/4.11/
> enabled=1
> gpgcheck=0 I also tried to change it to 4.13.13.1.0 but it's not working
> another question, do I need to use systemvmtemplate-4.11.3-kvm.qcow2.bz2
> with 4.13.1.0 or can I use a recent qcow file? thank you for yout help.
>
>

-- 

Andrija Panić

CloudStack 4.13.1.0 download

[Luis Martinez]

Hi Group

I am reading the documentation for 4.13.1.0 and the repository is 
pointing to 4.11, is this correct?


http://docs.cloudstack.apache.org/en/4.13.1.0/quickinstallationguide/qig.html

[cloudstack]
name=cloudstack
baseurl=http://download.cloudstack.org/centos/7/4.11/
enabled=1
gpgcheck=0 I also tried to change it to 4.13.13.1.0 but it's not working 
another question, do I need to use systemvmtemplate-4.11.3-kvm.qcow2.bz2 
with 4.13.1.0 or can I use a recent qcow file? thank you for yout help.

Re: VirtIO Network Adapter for system vms on KVM Hypervisor

[Andrija Panic]

Hey, good to hear from you.

If you want to thank me - I would appreciate it if you could test other
Debian 6/7/8/9 (whatever OS type is available there) and report which of
those gives Intel NICs (a bug, by all means, but hard to say where exactly)
Which CentOS7 version exactly? Which qemu-kvm/libvirt version are you
running?

Cheers

On Fri, 15 May 2020 at 16:19, Rafal Turkiewicz  wrote:

> Andrija,
>
> You are the man! I have changed the OS Type to the default Debian 5 x64
> and boom! All sorted.
>
> It's really odd that picking older OS Type solved the issue where in fact
> the systemVM is running Debian 9. Is this a BUG of some sort?
>
> I might try and experiment with other OS Type Debian version X to see
> where it falls but for now I'm all happy!
>
> Once again thank you very much for the pointer!
>
> Raf
>
> On 2020/05/15 13:51:01, Andrija Panic  wrote:
> > In the upgrade guide, we always advise (when registering the new systeVM
> > template) to go as:
> >
> >   OS Type: Debian GNU/Linux 7.0 (64-bit) (or the highest Debian
> release
> > number available in the dropdown)
> >
> > That being said, in the clean 4.13 installation, the OS type is set to
> > Debian 5 x64 - so try each version and in between destroy VR (i.e.
> restart
> > the network with cleanup) and observe "lspci" if virtio or intel NICs -
> but
> > also make sure that each time the VR is created on KVM host (i.e. not on
> > XEN).
> >
> > In order to change OS type for systemVM template, you will have to use DB
> > - modify the "vm_template" table - update the "guest_os_id" field value
> for
> > that specific template, to the ID from the "guest_os" table where
> > name=Debian XXX 64.
> >
> > Hope that solves the issue - should by all means.
> >
> > Regards
> > Andrija
> >
> >
> > On Fri, 15 May 2020 at 15:33, Rafal Turkiewicz 
> wrote:
> >
> > > Hello Andrija,
> > >
> > > Thanks for your input the OS Type for the systemVM template is set to
> > > "Debian GNU/Linux 8 (64-bit)"
> > >
> > > I think I forgot to mention a very important aspect of my setup. This
> > > Cloudstack instance is powering XenServer and KVM where KVM was added
> > > recently.
> > >
> > > Your message made me think and look at my other (test lab) setup where
> > > CloudStack is only powering KVM hypervisors. I can confirm all VRs are
> > > running with virtio which implies there got to be something on the my
> mixed
> > > HV CloudStack.
> > >
> > > I will keep looking into this but if you have any further thoughts on
> this
> > > please let me know.
> > >
> > > Raf
> > >
> > > On 2020/05/15 11:14:37, Andrija Panic  wrote:
> > > > Rafal,
> > > >
> > > > what is the OS type you defined for the systemVM template?
> > > >
> > > > In my env, VR (VPC) - all interfaces are VirtIO.
> > > >
> > > > Best
> > > > Andrija
> > > >
> > > > On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz 
> > > wrote:
> > > >
> > > > > Platform:
> > > > > CloudStack 4.11.2 on CentOS 7
> > > > > KVM Hypervisor on CentOS 7
> > > > >
> > > > > I have found some throughput issues on our VirtualRuters and I've
> > > tracked
> > > > > it down to CPU IRQ hitting 99% on the VR which was related to NIC
> > > > > interrupts.
> > > > >
> > > > > I decided to lookup what NIC is being emulated on the VRs; lsmod
> listed
> > > > > three Intel NICs:
> > > > >
> > > > > 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit
> Ethernet
> > > > > Controller (rev 03)
> > > > > 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
> Ethernet
> > > > > Controller (rev 03)
> > > > > 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit
> Ethernet
> > > > > Controller (rev 03)
> > > > >
> > > > > All my regular VMs are using Virtio network devices as specified
> within
> > > > > template settings nicAdapter=virtio
> > > > >
> > > > > When I manually updated the user_vm_details table for a VR with
> > > > > nicAdapter=virtio and restarted the VR everything came up as
> expected,
> > > the
> > > > > VR was started with virtio NICs and the IRQ issue was gone, also
> the
> > > > > throughput doubled. Now lspci on the VR was showing:
> > > > >
> > > > > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > > > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > > > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > > >
> > > > > The problem I have is getting the nicAdapter setting at systemvm
> > > template
> > > > > level like I do for regular VMs so that all VRs are deployed with
> > > virtio
> > > > > network adapter. I don't want to set this manually for every
> network I
> > > > > deploy. So I went to Templates -> Mysystemvm template -> Settings
> ->
> > > Add
> > > > > Setting
> > > > >
> > > > > Name:  nicAdapter
> > > > > Value: virtio
> > > > >
> > > > > BUT it just looks to me like systemvms don't honour
> vm_template_details
> > > > > table where nicAdapter is specified. When a VR gets created, I
> looked
> > > up
> > > > > content 

Re: VirtIO Network Adapter for system vms on KVM Hypervisor

[Rafal Turkiewicz]

Andrija,

You are the man! I have changed the OS Type to the default Debian 5 x64 and 
boom! All sorted.

It's really odd that picking older OS Type solved the issue where in fact the 
systemVM is running Debian 9. Is this a BUG of some sort?

I might try and experiment with other OS Type Debian version X to see where it 
falls but for now I'm all happy!

Once again thank you very much for the pointer!

Raf

On 2020/05/15 13:51:01, Andrija Panic  wrote: 
> In the upgrade guide, we always advise (when registering the new systeVM
> template) to go as:
> 
>   OS Type: Debian GNU/Linux 7.0 (64-bit) (or the highest Debian release
> number available in the dropdown)
> 
> That being said, in the clean 4.13 installation, the OS type is set to
> Debian 5 x64 - so try each version and in between destroy VR (i.e. restart
> the network with cleanup) and observe "lspci" if virtio or intel NICs - but
> also make sure that each time the VR is created on KVM host (i.e. not on
> XEN).
> 
> In order to change OS type for systemVM template, you will have to use DB
> - modify the "vm_template" table - update the "guest_os_id" field value for
> that specific template, to the ID from the "guest_os" table where
> name=Debian XXX 64.
> 
> Hope that solves the issue - should by all means.
> 
> Regards
> Andrija
> 
> 
> On Fri, 15 May 2020 at 15:33, Rafal Turkiewicz  wrote:
> 
> > Hello Andrija,
> >
> > Thanks for your input the OS Type for the systemVM template is set to
> > "Debian GNU/Linux 8 (64-bit)"
> >
> > I think I forgot to mention a very important aspect of my setup. This
> > Cloudstack instance is powering XenServer and KVM where KVM was added
> > recently.
> >
> > Your message made me think and look at my other (test lab) setup where
> > CloudStack is only powering KVM hypervisors. I can confirm all VRs are
> > running with virtio which implies there got to be something on the my mixed
> > HV CloudStack.
> >
> > I will keep looking into this but if you have any further thoughts on this
> > please let me know.
> >
> > Raf
> >
> > On 2020/05/15 11:14:37, Andrija Panic  wrote:
> > > Rafal,
> > >
> > > what is the OS type you defined for the systemVM template?
> > >
> > > In my env, VR (VPC) - all interfaces are VirtIO.
> > >
> > > Best
> > > Andrija
> > >
> > > On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz 
> > wrote:
> > >
> > > > Platform:
> > > > CloudStack 4.11.2 on CentOS 7
> > > > KVM Hypervisor on CentOS 7
> > > >
> > > > I have found some throughput issues on our VirtualRuters and I've
> > tracked
> > > > it down to CPU IRQ hitting 99% on the VR which was related to NIC
> > > > interrupts.
> > > >
> > > > I decided to lookup what NIC is being emulated on the VRs; lsmod listed
> > > > three Intel NICs:
> > > >
> > > > 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > > Controller (rev 03)
> > > > 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > > Controller (rev 03)
> > > > 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > > Controller (rev 03)
> > > >
> > > > All my regular VMs are using Virtio network devices as specified within
> > > > template settings nicAdapter=virtio
> > > >
> > > > When I manually updated the user_vm_details table for a VR with
> > > > nicAdapter=virtio and restarted the VR everything came up as expected,
> > the
> > > > VR was started with virtio NICs and the IRQ issue was gone, also the
> > > > throughput doubled. Now lspci on the VR was showing:
> > > >
> > > > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > >
> > > > The problem I have is getting the nicAdapter setting at systemvm
> > template
> > > > level like I do for regular VMs so that all VRs are deployed with
> > virtio
> > > > network adapter. I don't want to set this manually for every network I
> > > > deploy. So I went to Templates -> Mysystemvm template -> Settings ->
> > Add
> > > > Setting
> > > >
> > > > Name:  nicAdapter
> > > > Value: virtio
> > > >
> > > > BUT it just looks to me like systemvms don't honour vm_template_details
> > > > table where nicAdapter is specified. When a VR gets created, I looked
> > up
> > > > content of the user_vm_details for the VR and found nicAdapter=virio is
> > > > missing but I would expect it to be there.
> > > >
> > > > If there is anyone running CloudStack with KVM who could help on this
> > that
> > > > would be great. It might well be a BUG and needs to be reported as
> > such not
> > > > sure at this stage.
> > > >
> > > > If any of the above is not entirely clear please let me know and I
> > will try
> > > > my best to explain in more detail.
> > > >
> > > > Thanks
> > > > Raf
> > > >
> > >
> > >
> > > --
> > >
> > > Andrija Panić
> > >
> >
> 
> 
> -- 
> 
> Andrija Panić
> 

Re: Hello and first doubts!

[Simon Weller]

Welcome Augusto!

I'll do my best to answer your questions and I'm sure others will chime in as 
well.


  1.  CloudStack is designed to scale to massive levels and supports various 
levels of availability. Typically, if you are going to be building out services 
in different geographic areas, you'd separate those into CloudStack Regions.  A 
region is designed to be completely self-contained, with no dependencies on 
other regions. Please see this URL for more detail on this - 
https://docs.cloudstack.apache.org/en/latest/conceptsandterminology/concepts.html#cloudstack-terminology
  2.  AWS and other vendors do offer some bare metal services. As long as you 
have direct access to the underlying server hardware, you could definitely 
utilize them as CloudStack Hosts. CloudStack does support a number of 
hypervisors, either directly (as in the case with KVM), or via other management 
systems (such as VMWare with vSphere). Think of CloudStack as an orchestrator 
or orchestrators.
  3.  CloudStack networking can be deploying in a number of ways. At the most 
simplistic level, you can deploy hosts and use host based security groups for 
separation with little to no complexity on the underlay network.  You can also 
utilize advanced networking and separate Virtual Private Clouds (VPCs) via 
VLANs, VXLANs or other tunnel protocols depending on what the underlining 
hypervisor supports.

CloudStack is in use by large cloud providers and huge corporations world wide 
and it built to be extremely robust, while still providing the flexibility that 
different entities require. We have a large community and a lot of vendor 
integrations allowing the cloud operator to mix and match technologies that 
better suit their needs.

-Si




From: i...@defendhosting.com 
Sent: Friday, May 15, 2020 7:05 AM
To: users@cloudstack.apache.org 
Subject: Hello and first doubts!


Hello,

My name is Augusto and I am new here. Hello to all. Glad to be here.

I am new in cloudstack and I have some doubts that may be can be
answered here. I already provide server and vps service, but I would
like to provide cloud service with cloudstack in several locations.

First of all, I am sorry because my cloudstack knowledge is near to
null. I plan to start now, and for that reason I have these doubs:

1).- The master and the hosts must be in same datacenter?. I mean, if I
install a master in europe, can I manage the hosts in Europe, USA,
Canada and other locations?. For example using a hetzner server for
master and ovh or sys for hosts.

2).- I saw some videos about vmware, indicating that it is possible to
use AWS infraestructure to deploy hosts and use their infraestructure to
growup creating several "virtual datacenters". That can be done with
cloudstack? (or with other major clouds)

3).- If hosts are deployed in same datacenter, for example OVH, Is there
additional tasks to acomplish regarding the network? I mean, creating
for example an vRack or it is not necessary and cloudstack will manage all?

Thank you for your

--

�� DEFEND HOSTING - www.defendhosting.com - A 
Company You Can Trust
�� Shared Hosting | VPS | Dedicated Servers | SEO | PBX, CRM and SEO Servers
�� USA/EU Locations | Fast Network/Server Backbone Connection
�� Best Value For Your Money | Outstanding Uptime | Customer Tailored
Support | Money-Back Guarantee

--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Boris Stoyanov]

I'll have to -1 RC3, we've discovered details about an issue which is causing 
severe consequences with a particular hypervisor in the afternoon. We'll need 
more time to investigate before disclosing. 

Bobby.

On 15.05.20, 9:12, "Boris Stoyanov"  wrote:

+1 (binding) 

I've executed upgrade tests with the following configurations: 

4.13.1 with KVM on CentOS7 hosts
4.13 with VMware6.5 hosts
4.11.3 with KVM on CentOS7 hosts 
4.11.2 with XenServer7 hosts 
4.11.1 with VMware 6.7 
4.9.3 with XenServer 7 hosts 
4.9.2 with KVM on CentOS 7 hosts 

Also I've run basic lifecycle operations on the following components: 
VMs
Volumes 
Infra (zones, pod, clusters, hosts)
Networks 
and more

I did not come across any problems during this testing. 

Thanks,
Bobby.


On 11.05.20, 18:21, "Andrija Panic"  wrote:

Hi All,

I've created a 4.14.0.0 release (RC3), with the following artefacts up 
for
testing and a vote:

Git Branch and Commit SH:

https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503
Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/

PGP release keys (signed using 3DC01AE8):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 14th May 2020, 17.00 CET (72h).

For sanity in tallying the vote, can PMC members please be sure to 
indicate
"(binding)" with their vote?

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Additional information:

For users' convenience, I've built packages from
6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 repository 
here:
http://packages.shapeblue.com/testing/41400rc3/  (CentOS 7 and
Debian/generic, both with noredist support)
and here

https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/
 (Ubuntu 18.04 specific, no noredist support - thanks to Gabriel):

The release notes are still work-in-progress, but for the upgrade
instructions (including the new systemVM templates) you may refer to the
following URL:

https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html

4.14.0.0 systemVM templates are available from here:
http://download.cloudstack.org/systemvm/4.14/

NOTES on issues fixed in this RC3 release:

(this one does *NOT* require a full retest if you were testing RC1/RC2
already - just if you were affected this issue):
- https://github.com/apache/cloudstack/pull/4064 - affects hostnames 
when
attaching a VM to additional networks

Regards,


Andrija Panić





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

Re: VirtIO Network Adapter for system vms on KVM Hypervisor

[Andrija Panic]

In the upgrade guide, we always advise (when registering the new systeVM
template) to go as:

  OS Type: Debian GNU/Linux 7.0 (64-bit) (or the highest Debian release
number available in the dropdown)

That being said, in the clean 4.13 installation, the OS type is set to
Debian 5 x64 - so try each version and in between destroy VR (i.e. restart
the network with cleanup) and observe "lspci" if virtio or intel NICs - but
also make sure that each time the VR is created on KVM host (i.e. not on
XEN).

In order to change OS type for systemVM template, you will have to use DB
- modify the "vm_template" table - update the "guest_os_id" field value for
that specific template, to the ID from the "guest_os" table where
name=Debian XXX 64.

Hope that solves the issue - should by all means.

Regards
Andrija


On Fri, 15 May 2020 at 15:33, Rafal Turkiewicz  wrote:

> Hello Andrija,
>
> Thanks for your input the OS Type for the systemVM template is set to
> "Debian GNU/Linux 8 (64-bit)"
>
> I think I forgot to mention a very important aspect of my setup. This
> Cloudstack instance is powering XenServer and KVM where KVM was added
> recently.
>
> Your message made me think and look at my other (test lab) setup where
> CloudStack is only powering KVM hypervisors. I can confirm all VRs are
> running with virtio which implies there got to be something on the my mixed
> HV CloudStack.
>
> I will keep looking into this but if you have any further thoughts on this
> please let me know.
>
> Raf
>
> On 2020/05/15 11:14:37, Andrija Panic  wrote:
> > Rafal,
> >
> > what is the OS type you defined for the systemVM template?
> >
> > In my env, VR (VPC) - all interfaces are VirtIO.
> >
> > Best
> > Andrija
> >
> > On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz 
> wrote:
> >
> > > Platform:
> > > CloudStack 4.11.2 on CentOS 7
> > > KVM Hypervisor on CentOS 7
> > >
> > > I have found some throughput issues on our VirtualRuters and I've
> tracked
> > > it down to CPU IRQ hitting 99% on the VR which was related to NIC
> > > interrupts.
> > >
> > > I decided to lookup what NIC is being emulated on the VRs; lsmod listed
> > > three Intel NICs:
> > >
> > > 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > Controller (rev 03)
> > > 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > Controller (rev 03)
> > > 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > > Controller (rev 03)
> > >
> > > All my regular VMs are using Virtio network devices as specified within
> > > template settings nicAdapter=virtio
> > >
> > > When I manually updated the user_vm_details table for a VR with
> > > nicAdapter=virtio and restarted the VR everything came up as expected,
> the
> > > VR was started with virtio NICs and the IRQ issue was gone, also the
> > > throughput doubled. Now lspci on the VR was showing:
> > >
> > > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
> > > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
> > >
> > > The problem I have is getting the nicAdapter setting at systemvm
> template
> > > level like I do for regular VMs so that all VRs are deployed with
> virtio
> > > network adapter. I don't want to set this manually for every network I
> > > deploy. So I went to Templates -> Mysystemvm template -> Settings ->
> Add
> > > Setting
> > >
> > > Name:  nicAdapter
> > > Value: virtio
> > >
> > > BUT it just looks to me like systemvms don't honour vm_template_details
> > > table where nicAdapter is specified. When a VR gets created, I looked
> up
> > > content of the user_vm_details for the VR and found nicAdapter=virio is
> > > missing but I would expect it to be there.
> > >
> > > If there is anyone running CloudStack with KVM who could help on this
> that
> > > would be great. It might well be a BUG and needs to be reported as
> such not
> > > sure at this stage.
> > >
> > > If any of the above is not entirely clear please let me know and I
> will try
> > > my best to explain in more detail.
> > >
> > > Thanks
> > > Raf
> > >
> >
> >
> > --
> >
> > Andrija Panić
> >
>


-- 

Andrija Panić

Re: VirtIO Network Adapter for system vms on KVM Hypervisor

[Rafal Turkiewicz]

Hello Andrija,

Thanks for your input the OS Type for the systemVM template is set to "Debian 
GNU/Linux 8 (64-bit)"

I think I forgot to mention a very important aspect of my setup. This 
Cloudstack instance is powering XenServer and KVM where KVM was added recently. 

Your message made me think and look at my other (test lab) setup where 
CloudStack is only powering KVM hypervisors. I can confirm all VRs are running 
with virtio which implies there got to be something on the my mixed HV 
CloudStack.

I will keep looking into this but if you have any further thoughts on this 
please let me know.

Raf 

On 2020/05/15 11:14:37, Andrija Panic  wrote: 
> Rafal,
> 
> what is the OS type you defined for the systemVM template?
> 
> In my env, VR (VPC) - all interfaces are VirtIO.
> 
> Best
> Andrija
> 
> On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz  wrote:
> 
> > Platform:
> > CloudStack 4.11.2 on CentOS 7
> > KVM Hypervisor on CentOS 7
> >
> > I have found some throughput issues on our VirtualRuters and I've tracked
> > it down to CPU IRQ hitting 99% on the VR which was related to NIC
> > interrupts.
> >
> > I decided to lookup what NIC is being emulated on the VRs; lsmod listed
> > three Intel NICs:
> >
> > 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > Controller (rev 03)
> > 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > Controller (rev 03)
> > 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> > Controller (rev 03)
> >
> > All my regular VMs are using Virtio network devices as specified within
> > template settings nicAdapter=virtio
> >
> > When I manually updated the user_vm_details table for a VR with
> > nicAdapter=virtio and restarted the VR everything came up as expected, the
> > VR was started with virtio NICs and the IRQ issue was gone, also the
> > throughput doubled. Now lspci on the VR was showing:
> >
> > 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> > 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
> > 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
> >
> > The problem I have is getting the nicAdapter setting at systemvm template
> > level like I do for regular VMs so that all VRs are deployed with virtio
> > network adapter. I don't want to set this manually for every network I
> > deploy. So I went to Templates -> Mysystemvm template -> Settings -> Add
> > Setting
> >
> > Name:  nicAdapter
> > Value: virtio
> >
> > BUT it just looks to me like systemvms don't honour vm_template_details
> > table where nicAdapter is specified. When a VR gets created, I looked up
> > content of the user_vm_details for the VR and found nicAdapter=virio is
> > missing but I would expect it to be there.
> >
> > If there is anyone running CloudStack with KVM who could help on this that
> > would be great. It might well be a BUG and needs to be reported as such not
> > sure at this stage.
> >
> > If any of the above is not entirely clear please let me know and I will try
> > my best to explain in more detail.
> >
> > Thanks
> > Raf
> >
> 
> 
> -- 
> 
> Andrija Panić
> 

Hello and first doubts!

[info]

Hello,

My name is Augusto and I am new here. Hello to all. Glad to be here.

I am new in cloudstack and I have some doubts that may be can be 
answered here. I already provide server and vps service, but I would 
like to provide cloud service with cloudstack in several locations.


First of all, I am sorry because my cloudstack knowledge is near to 
null. I plan to start now, and for that reason I have these doubs:


1).- The master and the hosts must be in same datacenter?. I mean, if I 
install a master in europe, can I manage the hosts in Europe, USA, 
Canada and other locations?. For example using a hetzner server for 
master and ovh or sys for hosts.


2).- I saw some videos about vmware, indicating that it is possible to 
use AWS infraestructure to deploy hosts and use their infraestructure to 
growup creating several "virtual datacenters". That can be done with 
cloudstack? (or with other major clouds)


3).- If hosts are deployed in same datacenter, for example OVH, Is there 
additional tasks to acomplish regarding the network? I mean, creating 
for example an vRack or it is not necessary and cloudstack will manage all?


Thank you for your

--

█ DEFEND HOSTING - www.defendhosting.com - A Company You Can Trust
█ Shared Hosting | VPS | Dedicated Servers | SEO | PBX, CRM and SEO Servers
█ USA/EU Locations | Fast Network/Server Backbone Connection
█ Best Value For Your Money | Outstanding Uptime | Customer Tailored 
Support | Money-Back Guarantee


--
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

Re: VirtIO Network Adapter for system vms on KVM Hypervisor

[Andrija Panic]

Rafal,

what is the OS type you defined for the systemVM template?

In my env, VR (VPC) - all interfaces are VirtIO.

Best
Andrija

On Fri, 15 May 2020 at 12:14, Rafal Turkiewicz  wrote:

> Platform:
> CloudStack 4.11.2 on CentOS 7
> KVM Hypervisor on CentOS 7
>
> I have found some throughput issues on our VirtualRuters and I've tracked
> it down to CPU IRQ hitting 99% on the VR which was related to NIC
> interrupts.
>
> I decided to lookup what NIC is being emulated on the VRs; lsmod listed
> three Intel NICs:
>
> 00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> Controller (rev 03)
> 00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> Controller (rev 03)
> 00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
> Controller (rev 03)
>
> All my regular VMs are using Virtio network devices as specified within
> template settings nicAdapter=virtio
>
> When I manually updated the user_vm_details table for a VR with
> nicAdapter=virtio and restarted the VR everything came up as expected, the
> VR was started with virtio NICs and the IRQ issue was gone, also the
> throughput doubled. Now lspci on the VR was showing:
>
> 00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
> 00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
> 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device
>
> The problem I have is getting the nicAdapter setting at systemvm template
> level like I do for regular VMs so that all VRs are deployed with virtio
> network adapter. I don't want to set this manually for every network I
> deploy. So I went to Templates -> Mysystemvm template -> Settings -> Add
> Setting
>
> Name:  nicAdapter
> Value: virtio
>
> BUT it just looks to me like systemvms don't honour vm_template_details
> table where nicAdapter is specified. When a VR gets created, I looked up
> content of the user_vm_details for the VR and found nicAdapter=virio is
> missing but I would expect it to be there.
>
> If there is anyone running CloudStack with KVM who could help on this that
> would be great. It might well be a BUG and needs to be reported as such not
> sure at this stage.
>
> If any of the above is not entirely clear please let me know and I will try
> my best to explain in more detail.
>
> Thanks
> Raf
>


-- 

Andrija Panić

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Andrija Panic]

+1 (binding)

involved in many things around this one, overall looking good.

On Fri, 15 May 2020 at 08:13, Boris Stoyanov 
wrote:

> +1 (binding)
>
> I've executed upgrade tests with the following configurations:
>
> 4.13.1 with KVM on CentOS7 hosts
> 4.13 with VMware6.5 hosts
> 4.11.3 with KVM on CentOS7 hosts
> 4.11.2 with XenServer7 hosts
> 4.11.1 with VMware 6.7
> 4.9.3 with XenServer 7 hosts
> 4.9.2 with KVM on CentOS 7 hosts
>
> Also I've run basic lifecycle operations on the following components:
> VMs
> Volumes
> Infra (zones, pod, clusters, hosts)
> Networks
> and more
>
> I did not come across any problems during this testing.
>
> Thanks,
> Bobby.
>
>
> On 11.05.20, 18:21, "Andrija Panic"  wrote:
>
> Hi All,
>
> I've created a 4.14.0.0 release (RC3), with the following artefacts up
> for
> testing and a vote:
>
> Git Branch and Commit SH:
>
> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503
> Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/
>
> PGP release keys (signed using 3DC01AE8):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> The vote will be open until 14th May 2020, 17.00 CET (72h).
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate
> "(binding)" with their vote?
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
> Additional information:
>
> For users' convenience, I've built packages from
> 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 repository
> here:
> http://packages.shapeblue.com/testing/41400rc3/  (CentOS 7 and
> Debian/generic, both with noredist support)
> and here
>
> https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/
>  (Ubuntu 18.04 specific, no noredist support - thanks to Gabriel):
>
> The release notes are still work-in-progress, but for the upgrade
> instructions (including the new systemVM templates) you may refer to
> the
> following URL:
>
> https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html
>
> 4.14.0.0 systemVM templates are available from here:
> http://download.cloudstack.org/systemvm/4.14/
>
> NOTES on issues fixed in this RC3 release:
>
> (this one does *NOT* require a full retest if you were testing RC1/RC2
> already - just if you were affected this issue):
> - https://github.com/apache/cloudstack/pull/4064 - affects hostnames
> when
> attaching a VM to additional networks
>
> Regards,
>
>
> Andrija Panić
>
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
> @shapeblue
>
>
>
>

-- 

Andrija Panić

VirtIO Network Adapter for system vms on KVM Hypervisor

[Rafal Turkiewicz]

Platform:
CloudStack 4.11.2 on CentOS 7
KVM Hypervisor on CentOS 7

I have found some throughput issues on our VirtualRuters and I've tracked
it down to CPU IRQ hitting 99% on the VR which was related to NIC
interrupts.

I decided to lookup what NIC is being emulated on the VRs; lsmod listed
three Intel NICs:

00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
Controller (rev 03)
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
Controller (rev 03)
00:05.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet
Controller (rev 03)

All my regular VMs are using Virtio network devices as specified within
template settings nicAdapter=virtio

When I manually updated the user_vm_details table for a VR with
nicAdapter=virtio and restarted the VR everything came up as expected, the
VR was started with virtio NICs and the IRQ issue was gone, also the
throughput doubled. Now lspci on the VR was showing:

00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
00:04.0 Ethernet controller: Red Hat, Inc Virtio network device
00:05.0 Ethernet controller: Red Hat, Inc Virtio network device

The problem I have is getting the nicAdapter setting at systemvm template
level like I do for regular VMs so that all VRs are deployed with virtio
network adapter. I don't want to set this manually for every network I
deploy. So I went to Templates -> Mysystemvm template -> Settings -> Add
Setting

Name:  nicAdapter
Value: virtio

BUT it just looks to me like systemvms don't honour vm_template_details
table where nicAdapter is specified. When a VR gets created, I looked up
content of the user_vm_details for the VR and found nicAdapter=virio is
missing but I would expect it to be there.

If there is anyone running CloudStack with KVM who could help on this that
would be great. It might well be a BUG and needs to be reported as such not
sure at this stage.

If any of the above is not entirely clear please let me know and I will try
my best to explain in more detail.

Thanks
Raf

Re: Cloudstack Upgrade Filed

[hanumant borwandkar]

Hi,

Thanks for the replies i will try to reproduce errors again may be i am
doing anything wrong., But I referring latest documentation relating
upgrade from 4.11.x to 4.13

Not sure why I am getting access denied & need of  super user previledges
error as I am upgrading with root user and yum upgrade command and using
mentioned yum repo in documentation

As there are two management servers and I am using mariadb 5.5.65 from
centos7 repo in master slave scenario.

Both the  management server are upgraded from 4.11.0 to 4.11.3 successful
previously some months ago.

Regards,
Hanumant B

On Fri, May 15, 2020, 11:51 Thomas Joseph  wrote:

> Hello Hanumant
>
> Are you using the correct user for running the related scripts?
>
> *020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied;
> you need (at least one of) the SUPER privilege(s) for this
> operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
> (main:null) (logid:) Unable to execute upgrade
> scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
> denied; you need (at least one of) the SUPER privilege(s) for this
> operation*
>
> With regards
> Thomas Joseph
>
> On Fri, 15 May 2020, 5:20 am Luis,  wrote:
>
> > Hi. What lines did you use for the upgrade?
> >
> > Sent from Yahoo Mail on Android
> >
> >   On Thu, May 14, 2020 at 6:43 PM, hanumant borwandkar<
> > hanumant.borwand...@gmail.com> wrote:   HI,
> >
> > Trying to upgrade cloudstack 4.11.3 to 4.13 latest but unable get success
> > also tried to upgrade to 4.14-RC3 test build both time got same error as
> > follows.
> >
> > CentOS Linux release 7.6.1810 (Core)
> >
> >
> > ERROR
> > 2
> >
> >
> > *020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied;
> > you need (at least one of) the SUPER privilege(s) for this
> > operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
> > (main:null) (logid:) Unable to execute upgrade
> > scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
> > denied; you need (at least one of) the SUPER privilege(s) for this
> > operation*
> >
> >
> > logs
> > 2020-05-15 00:12:41,329 DEBUG [c.c.u.d.VersionDaoImpl] (main:null)
> (logid:)
> > Checking to see if the database is at a version before it was the version
> > table is created
> > 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> > (logid:) DB version = 4.11.3.0 Code Version = 4.13.1.0
> > 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> > (logid:) Database upgrade must be performed from 4.11.3.0 to 4.13.1.0
> > 2020-05-15 00:12:41,392 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
> > (logid:) Running upgrade Upgrade41120to41200 to upgrade from
> > 4.11.2.0-4.12.0.0 to 4.12.0.0
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- Licensed to the Apache Software Foundation (ASF) under one
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- or more contributor license agreements.  See the NOTICE file
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- distributed with this work for additional information
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- regarding copyright ownership.  The ASF licenses this file
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- to you under the Apache License, Version 2.0 (the
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- "License"); you may not use this file except in compliance
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- with the License.  You may obtain a copy of the License at
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > --
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > --  http://www.apache.org/licenses/LICENSE-2.0
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > --
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- Unless required by applicable law or agreed to in writing,
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- software distributed under the License is distributed on an
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> > 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- KIND, either express or implied.  See the License for the
> > 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > -- specific language governing permissions and limitations
> > 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) 

Re: Cloudstack Upgrade Filed

[Thomas Joseph]

Hello Hanumant

Are you using the correct user for running the related scripts?

*020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied;
you need (at least one of) the SUPER privilege(s) for this
operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
(main:null) (logid:) Unable to execute upgrade
scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
denied; you need (at least one of) the SUPER privilege(s) for this
operation*

With regards
Thomas Joseph

On Fri, 15 May 2020, 5:20 am Luis,  wrote:

> Hi. What lines did you use for the upgrade?
>
> Sent from Yahoo Mail on Android
>
>   On Thu, May 14, 2020 at 6:43 PM, hanumant borwandkar<
> hanumant.borwand...@gmail.com> wrote:   HI,
>
> Trying to upgrade cloudstack 4.11.3 to 4.13 latest but unable get success
> also tried to upgrade to 4.14-RC3 test build both time got same error as
> follows.
>
> CentOS Linux release 7.6.1810 (Core)
>
>
> ERROR
> 2
>
>
> *020-05-15 00:12:42,059 ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access denied;
> you need (at least one of) the SUPER privilege(s) for this
> operation2020-05-15 00:12:42,081 ERROR [c.c.u.DatabaseUpgradeChecker]
> (main:null) (logid:) Unable to execute upgrade
> scriptcom.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Access
> denied; you need (at least one of) the SUPER privilege(s) for this
> operation*
>
>
> logs
> 2020-05-15 00:12:41,329 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) (logid:)
> Checking to see if the database is at a version before it was the version
> table is created
> 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> (logid:) DB version = 4.11.3.0 Code Version = 4.13.1.0
> 2020-05-15 00:12:41,368 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
> (logid:) Database upgrade must be performed from 4.11.3.0 to 4.13.1.0
> 2020-05-15 00:12:41,392 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
> (logid:) Running upgrade Upgrade41120to41200 to upgrade from
> 4.11.2.0-4.12.0.0 to 4.12.0.0
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- Licensed to the Apache Software Foundation (ASF) under one
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- or more contributor license agreements.  See the NOTICE file
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- distributed with this work for additional information
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- regarding copyright ownership.  The ASF licenses this file
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- to you under the Apache License, Version 2.0 (the
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- "License"); you may not use this file except in compliance
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- with the License.  You may obtain a copy of the License at
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> --
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> --  http://www.apache.org/licenses/LICENSE-2.0
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> --
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- Unless required by applicable law or agreed to in writing,
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- software distributed under the License is distributed on an
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> 2020-05-15 00:12:41,397 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- KIND, either express or implied.  See the License for the
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- specific language governing permissions and limitations
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- under the License.
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> --;
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- Schema upgrade from 4.11.2.0 to 4.12.0.0
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> --;
> 2020-05-15 00:12:41,398 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- [CLOUDSTACK-10314] Add reason column to ACL rule table
> 2020-05-15 00:12:41,403 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> ALTER TABLE `cloud`.`network_acl_item` ADD COLUMN `reason` VARCHAR(2500)
> AFTER `display`
> 2020-05-15 00:12:41,442 DEBUG [c.c.u.d.ScriptRunner] (main:null) (logid:)
> -- [CLOUDSTACK-9846] Make provision to store content and subject for Alerts
> in separate columns.
> 2020-05-15 

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Boris Stoyanov]

+1 (binding) 

I've executed upgrade tests with the following configurations: 

4.13.1 with KVM on CentOS7 hosts
4.13 with VMware6.5 hosts
4.11.3 with KVM on CentOS7 hosts 
4.11.2 with XenServer7 hosts 
4.11.1 with VMware 6.7 
4.9.3 with XenServer 7 hosts 
4.9.2 with KVM on CentOS 7 hosts 

Also I've run basic lifecycle operations on the following components: 
VMs
Volumes 
Infra (zones, pod, clusters, hosts)
Networks 
and more

I did not come across any problems during this testing. 

Thanks,
Bobby.


On 11.05.20, 18:21, "Andrija Panic"  wrote:

Hi All,

I've created a 4.14.0.0 release (RC3), with the following artefacts up for
testing and a vote:

Git Branch and Commit SH:

https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.14.0.0-RC20200511T1503
Commit: 6f96b3b2b391a9b7d085f76bcafa3989d9832b4e

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.14.0.0/

PGP release keys (signed using 3DC01AE8):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

The vote will be open until 14th May 2020, 17.00 CET (72h).

For sanity in tallying the vote, can PMC members please be sure to indicate
"(binding)" with their vote?

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Additional information:

For users' convenience, I've built packages from
6f96b3b2b391a9b7d085f76bcafa3989d9832b4e and published RC3 repository here:
http://packages.shapeblue.com/testing/41400rc3/  (CentOS 7 and
Debian/generic, both with noredist support)
and here

https://download.cloudstack.org/testing/4.14.0.0-RC20200506T2028/ubuntu/bionic/
 (Ubuntu 18.04 specific, no noredist support - thanks to Gabriel):

The release notes are still work-in-progress, but for the upgrade
instructions (including the new systemVM templates) you may refer to the
following URL:
https://acs-www.shapeblue.com/docs/WIP-PROOFING/pr112/upgrading/index.html

4.14.0.0 systemVM templates are available from here:
http://download.cloudstack.org/systemvm/4.14/

NOTES on issues fixed in this RC3 release:

(this one does *NOT* require a full retest if you were testing RC1/RC2
already - just if you were affected this issue):
- https://github.com/apache/cloudstack/pull/4064 - affects hostnames when
attaching a VM to additional networks

Regards,


Andrija Panić



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