New L2 nework types are not shared

[Jean-Francois Nadeau]

Hi all,

I'm testing 4.11-rc1 and the new L2 network type feature as shown at
http://www.shapeblue.com/layer-2-networks-in-cloudstack/

I want to use this as a replacement to a shared network offering with no
DHCP which works to support an external DHCP server but still required to
fill some CIDR information.

I thought the intent was that L2 network type was to replace the previous
approach when required to integrate an existing network.

If I attempt to provision a VM in a project as the root admin using the L2
network I get denied... apparently because they are not shared and I can't
make them public.

('HTTP 531 response from CloudStack', , {u'errorcode': 531,
u'uuidList': [], u'cserrorcode': 4365, u'errortext': u'Unable to use
network with id= 7712102b-bbdf-4c54-bdbf-9fddfa16de46, permission denied'})

Provisioning in the root project works just fine  but really I want to
use L2 networks in user projects even if only the admin can do so.

Thoughts ?

Re: Intel meltdown/spectre kvm upgrade results

[Sebastian Gomez]

Good!

Thanks for sharing it, nice iniciative!

We have to upgrade the VMware clusters, but vmware is changing daily the
patch policy...
Once done I will try to remember to share too.



Regards.




Atentamente,
Sebastián Gómez

On Sat, Jan 13, 2018 at 5:59 AM, Ivan Kudryavtsev 
wrote:

> Hi, colleagues,
>
> just would like to share that yesterday successfuly upgraded my ubuntu
> 14.04 kvm cloud to custom built linux 4.14.11 keenel with ubuntu 2018/01/08
> intel cpu microcode update. Compute CPUs - Xeon E5-2670, Xeon X5650,
> everything works nice, no claims from customers, no sensitive load change.
> Live migration between new and old kernels goes well, back migration too.
> It seems that kvm, libvirt and qemu patches are not here yet for Ubuntu.
> Waiting for additional updates. Btw, It is CS4.3.
>
> Have a nice migration.
>

Re: Shape Blue Container Service

[Daan Hoogland]

Ghaith,

There is a 4.10 version in the code but not as a packaged installable.
If you’re comfortable with source installations have a look at 
https://github.com/shapeblue/ccs/tree/on-top-of-pr-2071-for-4.10
A release for 4.10 is planned but we do not have a date yet.

Hope that satisfies your query,

On 17/01/2018, 09:46, "Ghaith Bannoura"  wrote:

Hello All,

I'm trying to install shape blue container service , but I already have ACS 
version 4.9 what I read from the document that its supported on ACS  Version 
4.6 ,

is it compatible on version 4.9 or 4.10 since I urgently need to implement 
it on my cloud ?



Best Regards,

Ghaith Bannoura
Senior System Administrator
MCT, MCSE (Messaging, Server Infrastructure)
MCSA (Windows Server 2008, 2012), MCP






daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Ron Wheeler]

It might also be helpful to know what version of ACS as well.
Some indication of your plan/desire to upgrade ACS, hypervisor, or 
management server operating system might be helpful.
There is a big difference between the situation where someone is running 
ACS 4.9x on CentOS 6 and wants to upgrade to ACS 4.12 while keeping 
CentOS 6 and another environment where the planned upgrade to ACS4.12 
will be done at the same time as an upgrade to CentOS 7.x.


Is it fair to say that any proposed changes in this area will occur in 
4.12 at the earliest and will not likely occur before summer 2018?



Ron


On 17/01/2018 4:23 AM, Paul Angus wrote:

Thanks Eric,

As you'll see from the intro email to this thread, the purpose here is to 
ensure that we don't strand a 'non-trivial' number of users by dropping support 
for any given hypervisor, or management server operating system.

Hence the request to users to let the community know what they are using, so 
that a fact-based community consensus can be reached.


Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Eric Lee Green [mailto:eric.lee.gr...@gmail.com]
Sent: 16 January 2018 23:36
To: users@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors


This is the type of discussion that I wanted to open - the argument
that I see for earlier dropping of v6 is that - Between May 2018 and
q2 2020 RHEL/CentOS 6.x will only receive security and mission
critical updates, meanwhile packages on which we depend or may want to
utilise in the future are been deprecated or not developed for v6.x

But this has always been the case for Centos 6.x. It is running antique 
versions of everything, and has been doing so for quite some time. It is, for 
example, running versions of Gnome and init that have been obsolete for years. 
Same deal with the version of MySQL that it comes with.

The reality is that Centos 6.x guest support, at the very least, needs to be 
tested with each new version of Cloudstack until final EOL of Centos 6 in Q2 
2020. New versions of Cloudstack with new features not supported by Centos 6 
(such as LVM support for KVM, which requires the LIO storage stack) can require 
Centos 7 or later, but the last Cloudstack version that supports Centos 6.x as 
its server host should continue to receive bug fixes until Centos 6.x is EOL.

Making someone's IT investment obsolete is a way to irrelevancy.
Cloudstack is already an also-ran in the cloud marketplace. Making someone's IT 
investment obsolete before the official EOL time for their IT investment is a 
good way to have a mass migration away from your technology.

This doesn't particularly affect me since my Centos 6 virtualization hosts are 
not running Cloudstack and are going to be re-imaged to Centos
7 before being added to the Cloudstack cluster, but ignoring the IT environment that 
people actually live in, as versus the one we wish existed, is annoying regardless. A 
friend of mine once said of the state of ERP software, "enterprise software is dog 
food if dog food was being designed by cats." I.e., the people writing the software 
rarely have any understanding of how it is actually used by real life enterprises in real 
life environments. Don't be those people.


On 01/16/2018 09:58 AM, Paul Angus wrote:

Hi Eric,

This is the type of discussion that I wanted to open - the argument
that I see for earlier dropping of v6 is that - Between May 2018 and q2 2020 
RHEL/CentOS 6.x will only receive security and mission critical updates, 
meanwhile packages on which we depend or may want to utilise in the future are 
been deprecated or not developed for v6.x Also the testing and development 
burden on the CloudStack community increases as we try to maintain backward 
compatibility while including new versions.

Needing installation documentation for centos 7 is a great point, and something 
that we need to address regardless.


Does anyone else have a view, I'd really like to here from a wide range of 
people.

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue

   



-Original Message-
From: Eric Green [mailto:eric.lee.gr...@gmail.com]
Sent: 12 January 2018 17:24
To: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors

Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
11/30/2020. Jumping the gun a bit there, padme.

People on Centos 6 should certainly be working on a migration strategy right 
now, but the end is not here *yet*. Furthermore, the install documentation is 
still written for Centos 6 rather than Centos 7. That needs to be fixed before 
discontinuing support for Centos 6, eh?


On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:

+1 I've updated 

Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Boris Stoyanov]

I think I’ve hit a blocker when upgrading to 4.11

Here’s the jira id: https://issues.apache.org/jira/browse/CLOUDSTACK-10236

I’ve upgraded from 4.5 to 4.11, then I’ve logged in with admin and got session 
expired immediately.

Regards,
Boris Stoyanov


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On 17 Jan 2018, at 8:42, Tutkowski, Mike 
> wrote:

Hi everyone,

For the past couple days, I have been running the KVM managed-storage 
regression-test suite against RC1.

With the exception of one issue (more on this below), all of these tests have 
passed.

Tomorrow I plan to start in on the VMware-related managed-storage tests.

Once I’ve completed running those, I expect to move on to the XenServer-related 
managed-storage tests.

I ran these XenServer and VMware tests just prior to RC1 being created, so I 
suspect all of those tests will come back successful.

Now, with regards to the one issue I found on KVM with managed storage:

It relates to a new feature whereby you can online migrate the storage of a VM 
from NFS or Ceph to managed storage.

During the code-review process, I made a change per a suggestion and it 
introduced an issue with this feature. The solution is just a couple lines of 
code and only impacts this one use case. If you are testing this release 
candidate and don’t really care about this particular feature, it should not at 
all impact your ability to test RC1.

Thanks!
Mike

On Jan 15, 2018, at 4:33 AM, Rohit Yadav 
> wrote:

Hi All,

I've created a 4.11.0.0 release, with the following artifacts 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.11.0.0-RC20180115T1603
Commit: 1b8a532ba52127f388847690df70e65c6b46f4d4

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

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

The vote will be open for 72 hours.

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
1b8a532ba52127f388847690df70e65c6b46f4d4 and published RC1 repository here:
http://cloudstack.apt-get.eu/testing/4.11-rc1

The release notes are still work-in-progress, but the systemvmtemplate
upgrade section has been updated. You may refer the following for
systemvmtemplate upgrade testing:
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/index.html

4.11 systemvmtemplates are available from here:
https://download.cloudstack.org/systemvm/4.11/

Regards,
Rohit Yadav

Re: IP assignment

[Benjamin Naber]

Hi Asnka,

can you try to figure out what kind of setup you try run ?

The SystemVM Network Part is a part of the POD Network you will setup, by 
creating a POD / Cluster.

SystemVM´s will also get an IP address in public network.The public ip adresses 
they will used will be automaticly assinged based on the public network you 
have been created.

Kind Reagrds

Ben

> Asanka Gunasekara  hat am 17. Januar 2018 um 09:23 
> geschrieben:
> 
> Any idea, any one?
> 
> On 13 January 2018 at 23:54, Asanka Gunasekara  wrote:
> 
> > Hi any one can help me to understand the IP assignment in advance
> > networking its kind of confusing. Below is a small diagram as to what I
> > understand. Most of the confusion is at public network and system VMs.
> > 
> > https://snag.gy/txD9Fo.jpg
> > 
> > Is it correct, as long as routing is done properly, or can some one point
> > me to a document that I can read in this kind of scenario, goggled
> > documents did not help much.
> > 
> > Thanks and Regards
> > 
> > Asanka

RE: EOL for supported OSes & Hypervisors

[Paul Angus]

Hi Yiping,
Support for XenServer 7.1 LTSR will be in 4.11  - as with all things new, I'd 
recommend extensive testing of your exact use cases, but our smoke testing 
shows to be working fine.

Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Yiping Zhang [mailto:yzh...@marketo.com] 
Sent: 16 January 2018 22:39
To: users@cloudstack.apache.org
Subject: RE: EOL for supported OSes & Hypervisors

From end user’s perspective, listing just OS, hypervisor version’s EOL status 
is only half the story.  We need also to consider Apache CloudStack’s own EOL 
status to help users chose which combination of OS/Hypervisor/ACS versions to 
deploy for a stable and fully supported environment.

For example, I am currently on RHEL 6.7 + XenServer 6.5 SP1 + ACS 4.8.0. When 
all things are considered, my only upgrade path is to go with RHEL 6.7 + ACS 
4.9.3 + XenServer 7.0.  But hotfix for Meltdown/Spectre for XenServer 7.0 is 
not available either!   Therefore, I am stuck with my current environment!

BTW, is there any plan to add support for XenServer 7.1 LTSR to a stable ACS 
version?

Yiping

On 1/12/18, 9:24 AM, "Eric Green"  wrote:

Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
11/30/2020. Jumping the gun a bit there, padme. 

People on Centos 6 should certainly be working on a migration strategy 
right now, but the end is not here *yet*. Furthermore, the install 
documentation is still written for Centos 6 rather than Centos 7. That needs to 
be fixed before discontinuing support for Centos 6, eh?

> On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:
> 
> +1 I've updated the page with upcoming Ubuntu 18.04 LTS.
> 
> 
> After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
"declared" (they might still work with 4.12+ but in docs and by project we 
should officially support them) support for following:
> 
> 
> a. Hypervisor:
> 
> XenServer - 6.2, 6.5,
> 
> KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed, 
packages don't work I think?)
> 
> vSphere/Vmware - 4.x, 5.0, 5.1, 5.5
> 
> 
> b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and 
Ubuntu 12.04 (any non-systemd debian distro).
> 
> 
> Thoughts, comments?
> 

Re: kvm live volume migration

[Eric Green]

Theoretically on Centos 7 as the host KVM OS it could be done with a couple of 
pauses and the snapshotting mechanism built into qcow2, but there is no simple 
way to do it directly via virsh, the libvirtd/qemu control program that is used 
to manage virtualization. It's not as with issuing a simple vmotion 'migrate 
volume' call in Vmware. 

I scripted out how it would work without that direct support in libvirt/virsh 
and after looking at all the points where things could go wrong, honestly, I 
think we need to wait until there is support in libvirt/virsh to do this. virsh 
clearly has the capability internally to do live migration of storage, since it 
does this for live domain migration of local storage between machines when 
migrating KVM domains from one host to another, but that capability is not 
currently exposed in a way Cloudstack could use, at least not on Centos 7.


> On Jan 17, 2018, at 01:05, Piotr Pisz  wrote:
> 
> Hello,
> 
> Is there a chance that one day it will be possible to migrate volume (root 
> disk) of a live VM in KVM between storage pools (in CloudStack)?
> Like a storage vMotion in Vmware.
> 
> Best regards,
> Piotr
> 

RE: [PROPOSE] EOL for supported OSes & Hypervisors

[Paul Angus]

Thanks Eric,

As you'll see from the intro email to this thread, the purpose here is to 
ensure that we don't strand a 'non-trivial' number of users by dropping support 
for any given hypervisor, or management server operating system.

Hence the request to users to let the community know what they are using, so 
that a fact-based community consensus can be reached.


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Eric Lee Green [mailto:eric.lee.gr...@gmail.com] 
Sent: 16 January 2018 23:36
To: users@cloudstack.apache.org
Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors

> This is the type of discussion that I wanted to open - the argument 
> that I see for earlier dropping of v6 is that - Between May 2018 and 
> q2 2020 RHEL/CentOS 6.x will only receive security and mission 
> critical updates, meanwhile packages on which we depend or may want to 
> utilise in the future are been deprecated or not developed for v6.x
But this has always been the case for Centos 6.x. It is running antique 
versions of everything, and has been doing so for quite some time. It is, for 
example, running versions of Gnome and init that have been obsolete for years. 
Same deal with the version of MySQL that it comes with.

The reality is that Centos 6.x guest support, at the very least, needs to be 
tested with each new version of Cloudstack until final EOL of Centos 6 in Q2 
2020. New versions of Cloudstack with new features not supported by Centos 6 
(such as LVM support for KVM, which requires the LIO storage stack) can require 
Centos 7 or later, but the last Cloudstack version that supports Centos 6.x as 
its server host should continue to receive bug fixes until Centos 6.x is EOL.

Making someone's IT investment obsolete is a way to irrelevancy. 
Cloudstack is already an also-ran in the cloud marketplace. Making someone's IT 
investment obsolete before the official EOL time for their IT investment is a 
good way to have a mass migration away from your technology.

This doesn't particularly affect me since my Centos 6 virtualization hosts are 
not running Cloudstack and are going to be re-imaged to Centos
7 before being added to the Cloudstack cluster, but ignoring the IT environment 
that people actually live in, as versus the one we wish existed, is annoying 
regardless. A friend of mine once said of the state of ERP software, 
"enterprise software is dog food if dog food was being designed by cats." I.e., 
the people writing the software rarely have any understanding of how it is 
actually used by real life enterprises in real life environments. Don't be 
those people.


On 01/16/2018 09:58 AM, Paul Angus wrote:
> Hi Eric,
>
> This is the type of discussion that I wanted to open - the argument 
> that I see for earlier dropping of v6 is that - Between May 2018 and q2 2020 
> RHEL/CentOS 6.x will only receive security and mission critical updates, 
> meanwhile packages on which we depend or may want to utilise in the future 
> are been deprecated or not developed for v6.x Also the testing and 
> development burden on the CloudStack community increases as we try to 
> maintain backward compatibility while including new versions.
>
> Needing installation documentation for centos 7 is a great point, and 
> something that we need to address regardless.
>
>
> Does anyone else have a view, I'd really like to here from a wide range of 
> people.
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
>   
>
>
> -Original Message-
> From: Eric Green [mailto:eric.lee.gr...@gmail.com]
> Sent: 12 January 2018 17:24
> To: users@cloudstack.apache.org
> Cc: d...@cloudstack.apache.org
> Subject: Re: [PROPOSE] EOL for supported OSes & Hypervisors
>
> Official EOL for Centos 6 / RHEL 6 as declared by Red Hat Software is 
> 11/30/2020. Jumping the gun a bit there, padme.
>
> People on Centos 6 should certainly be working on a migration strategy right 
> now, but the end is not here *yet*. Furthermore, the install documentation is 
> still written for Centos 6 rather than Centos 7. That needs to be fixed 
> before discontinuing support for Centos 6, eh?
>
>> On Jan 12, 2018, at 04:35, Rohit Yadav  wrote:
>>
>> +1 I've updated the page with upcoming Ubuntu 18.04 LTS.
>>
>>
>> After 4.11, I think 4.12 (assuming releases by mid of 2018) should remove 
>> "declared" (they might still work with 4.12+ but in docs and by project we 
>> should officially support them) support for following:
>>
>>
>> a. Hypervisor:
>>
>> XenServer - 6.2, 6.5,
>>
>> KVM - CentOS6, RHEL6, Ubuntu12.04 (I think this is already removed, 
>> packages don't work I think?)
>>
>> vSphere/Vmware - 4.x, 5.0, 5.1, 5.5
>>
>>
>> b. Remove packaging for CentOS6.x, RHEL 6.x (the el6 packages), and Ubuntu 
>> 12.04 

kvm live volume migration

[Piotr Pisz]

Hello,

Is there a chance that one day it will be possible to migrate volume (root 
disk) of a live VM in KVM between storage pools (in CloudStack)?
Like a storage vMotion in Vmware.

Best regards,
Piotr

Shape Blue Container Service

[Ghaith Bannoura]

Hello All,

I'm trying to install shape blue container service , but I already have ACS 
version 4.9 what I read from the document that its supported on ACS  Version 
4.6 ,

is it compatible on version 4.9 or 4.10 since I urgently need to implement it 
on my cloud ?



Best Regards,

Ghaith Bannoura
Senior System Administrator
MCT, MCSE (Messaging, Server Infrastructure)
MCSA (Windows Server 2008, 2012), MCP

Re: IP assignment

[Asanka Gunasekara]

Any idea, any one?

On 13 January 2018 at 23:54, Asanka Gunasekara  wrote:

> Hi any one can help me to understand the IP assignment in advance
> networking its kind of confusing. Below is a small diagram as to what I
> understand. Most of the confusion is at public network and system VMs.
>
> https://snag.gy/txD9Fo.jpg
>
> Is it correct, as long as routing is done properly, or can some one point
> me to a document that I can read in this kind of scenario, goggled
> documents did not help much.
>
> Thanks and Regards
>
> Asanka
>