Intel meltdown/spectre kvm upgrade results

[Ivan Kudryavtsev]

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: [PROPOSE] EOL for supported OSes & Hypervisors

[Eric Green]

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: Not able to create the Secondary Storage and Console proxy Vms

[Dickson Lam (dilam)]

Hi Jagdish:

Thanks for look into it. How much memory is need for the system VMs? My esxi 
hosts has 38979 MB free memory and it will be strange that it do not have 
enough memory. Is the system VMs create under management server or on the esxi 
host?

About the VNET interfaces available to agent , can you give me an example what 
is a correct one look like?

On my management server, the output is the following:
# brctl show
bridge name bridge id   STP enabled interfaces
virbr0  8000.52540086bdae   yes virbr0-nic

Regards
Dickson

-Original Message-
From: Jagdish Patil [mailto:jagdishpatil...@gmail.com] 
Sent: Friday, January 12, 2018 5:34 AM
To: users@cloudstack.apache.org
Subject: Re: Not able to create the Secondary Storage and Console proxy Vms

Hi Dickson Lam,

VM's are not getting created due to
*com.cloud.exception.InsufficientServerCapacityException
*i.e. your host doesn't have enough free required memory to create system VM's. 
I have also checked the agent logs, it seems that your configuration is 
somewhat wrong as not all the required interfaces (VNET) are available to the 
agent. You can check interfaces using "brctl show" command.

On Thu, Jan 11, 2018 at 4:06 AM Dickson Lam (dilam)  wrote:

> Hi Jagdish/Gregoire:
>
> Enclosed please find the log files. I also change the log level to 
> DEBUG too.
>
> Thanks
> Dickson
>
>

Re: why instance must be stopped in order to update its affinity groups?

[Yiping Zhang]

Well, I am not a Java developer so this task is beyond my ability.   But I am 
more than willing to work with someone to come up with a feature 
description/user story and test it when it becomes available if it ever reaches 
that stage.

Thanks

Yiping

On 1/12/18, 7:10 AM, "Paul Angus"  wrote:

It a high level that is quite possible to do.  In practice there would be a 
number of safety nets in place, staged moving of VMs is always a little fraught 
without being able to reserve the resources ahead of time.

Are you volunteering to write it?

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: 11 January 2018 19:16
To: users@cloudstack.apache.org
Subject: Re: why instance must be stopped in order to update its affinity 
groups?

Paul, Marc:

Thanks for clarifying.

As cloud admin/operator, I do care about the instance’s placement and that 
is why I’d like to apply affinity groups to all instances whenever possible.

It sounds like there is no fundamental technical reasons that a running 
instance’s affinity group membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity 
group membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it 
is for migrating VM to another host in the same cluster. IOW, it does not 
involve storage migration.  If for some technical reasons that live migration 
can’t be done here, then that inner “if ... else ... end” block can be reduced 
to just “raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

Hi Yiping,

To add to Paul's comment, you also need to understand the goal of the
anti-affinity groups. If they don't care, you should simply block the
command so that your users don't use it (you should list the
createAffinityGroup command as a root admin call in the 
commands.properties
file by changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure 
that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> Hi Yiping,
>
> Anti-affinity groups deal with the placement of VMs when they are 
started,
> but doesn't/can't 'move' running VMs (it isn't like vSphere DRS).  If 
you
> change a VM's anti-affinity group, it's current placement on a host 
may
> suddenly become invalid.  As the Anti-Affinity group code isn't 
designed to
> move VMs, the safest option is to ensure that the VM is stopped when 
its
> group is changed so that when it is started again, CloudStack can then
> properly decide where it can/should go.
>
>
>
> 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: 10 January 2018 19:51
> To: users@cloudstack.apache.org
> Subject: why instance must be stopped in order to update its affinity
> groups?
>
> Hi, List:
>
> Can someone please explain why a VM instance must be in stopped state 
when
> updating its affinity group memberships?   This requirement is in 
“Feature
> assumptions” section of the original 4.2 design document (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> FS+-+Affinity-Anti-affinity+groups).
>
> My users either don’t understand or don’t care about affinity groups 
and I
> see a large number of instances with sub-optimal host placement (from
> anti-host affinity group point of view).  But it is too much trouble 
for me
> to coordinate with so many users to shut them down in order to fix 
their
> host placement.  What bad things would happen if a running instance’s
> affinity group is changed?
>
> Thanks,
  

RE: why instance must be stopped in order to update its affinity groups?

[Paul Angus]

It a high level that is quite possible to do.  In practice there would be a 
number of safety nets in place, staged moving of VMs is always a little fraught 
without being able to reserve the resources ahead of time.

Are you volunteering to write it?

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: 11 January 2018 19:16
To: users@cloudstack.apache.org
Subject: Re: why instance must be stopped in order to update its affinity 
groups?

Paul, Marc:

Thanks for clarifying.

As cloud admin/operator, I do care about the instance’s placement and that is 
why I’d like to apply affinity groups to all instances whenever possible.

It sounds like there is no fundamental technical reasons that a running 
instance’s affinity group membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity group 
membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it is 
for migrating VM to another host in the same cluster. IOW, it does not involve 
storage migration.  If for some technical reasons that live migration can’t be 
done here, then that inner “if ... else ... end” block can be reduced to just 
“raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

Hi Yiping,

To add to Paul's comment, you also need to understand the goal of the
anti-affinity groups. If they don't care, you should simply block the
command so that your users don't use it (you should list the
createAffinityGroup command as a root admin call in the commands.properties
file by changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> Hi Yiping,
>
> Anti-affinity groups deal with the placement of VMs when they are started,
> but doesn't/can't 'move' running VMs (it isn't like vSphere DRS).  If you
> change a VM's anti-affinity group, it's current placement on a host may
> suddenly become invalid.  As the Anti-Affinity group code isn't designed 
to
> move VMs, the safest option is to ensure that the VM is stopped when its
> group is changed so that when it is started again, CloudStack can then
> properly decide where it can/should go.
>
>
>
> 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: 10 January 2018 19:51
> To: users@cloudstack.apache.org
> Subject: why instance must be stopped in order to update its affinity
> groups?
>
> Hi, List:
>
> Can someone please explain why a VM instance must be in stopped state when
> updating its affinity group memberships?   This requirement is in “Feature
> assumptions” section of the original 4.2 design document (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> FS+-+Affinity-Anti-affinity+groups).
>
> My users either don’t understand or don’t care about affinity groups and I
> see a large number of instances with sub-optimal host placement (from
> anti-host affinity group point of view).  But it is too much trouble for 
me
> to coordinate with so many users to shut them down in order to fix their
> host placement.  What bad things would happen if a running instance’s
> affinity group is changed?
>
> Thanks,
>
> Yiping
>
>

Re: newly installed clondmonkey 5.3.3 won't run

[Rohit Yadav]

Hi Yiping,

Thanks for bringing this to attention, can you try installing cloudmonkey on a 
RHEL/CentOS7 VM, it's advised to use Python2.7.


My future plan is to rewrite the tool, possibly to export/build into a 
standalone binary (I've WIP golang port that might make into the cloudstack 
project soon).


- Rohit






From: Yiping Zhang 
Sent: Friday, January 12, 2018 4:38:20 AM
To: users@cloudstack.apache.org
Subject: newly installed clondmonkey 5.3.3 won't run

Hi, there:

I just installed the latest cloudmonkey (version 5.3.3) with pip on a RHEL 6.7 
VM, but when I run it, it throws a stack trace:

# pip install cloudmonkey
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please 
upgrade your Python. A future version of pip will drop support for Python 2.6
Collecting cloudmonkey
/usr/lib/python2.6/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:318:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. You can upgrade to a newer version of Python to solve this. For more 
information, see 
https://urllib3.readthedocs.io/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/usr/lib/python2.6/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. You can upgrade to a newer version of Python to solve 
this. For more information, see 
https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Using cached cloudmonkey-5.3.3.tar.gz
Requirement already satisfied: Pygments>=1.5 in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: argcomplete in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: dicttoxml in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: prettytable>=0.6 in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: requests in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: requests-toolbelt in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: chardet<3.1.0,>=3.0.2 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: certifi>=2017.4.17 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: urllib3<1.23,>=1.21.1 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: idna<2.7,>=2.5 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Installing collected packages: cloudmonkey
  Running setup.py install for cloudmonkey ... done
Successfully installed cloudmonkey-5.3.3
#
#
# cloudmonkey
Traceback (most recent call last):
  File "/usr/bin/cloudmonkey", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 2655, in 

working_set.require(__requires__)
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 648, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 546, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: requests-toolbelt
#

I have verified that requests-toolbelt (0.8.0) is installed.   How do I fix 
this?

Thanks

Yiping


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Rohit Yadav]

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


- Rohit






From: Paul Angus 
Sent: Thursday, January 11, 2018 10:41:08 PM
To: d...@cloudstack.apache.org; users@cloudstack.apache.org
Subject: [PROPOSE] EOL for supported OSes & Hypervisors

I've cross-posted this as it ultimately effects users more than developers.

I've created a wiki page with the EOL dates from the respective 'vendors' of 
our main supported hypervisors and mgmt. server OSes.
I've taken End Of Life to be the end of 'mainstream' support i.e. the point at 
which updates to packages will no longer be available.  And part of the 
discussion should be whether this EOL date should be moved out to consider end 
of security patching instead.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/WIP+-+UNOFFICIAL+-+PROPOSAL+-+EOL+Dates

I would like to propose, that as part of the release notes for the forthcoming 
4.11 release and as a general announcement, that we declare that:


  *   For any OSes/Hypervisors that are already EOL - we will no longer 
test/support them from the first release after June 2018 (6 months from now). 
And they will be removed from codebase (mainly the database) in the first 
release after Sept 2018 (9 months from now).
  *   We set End Of Support dates and Removal from Code dates for the remaining 
OSes/Hypervisors.  I propose that End Of Support should be the first release 
after EOL from the vendor, with code removal taking place in the first release 
which occurs after 6 months from 'vendor' EOL date.

Thoughts please


Kind regards,

Paul Angus


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




rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: Not able to create the Secondary Storage and Console proxy Vms

[Jagdish Patil]

Hi Dickson Lam,

VM's are not getting created due to
*com.cloud.exception.InsufficientServerCapacityException
*i.e. your host doesn't have enough free required memory to create system
VM's. I have also checked the agent logs, it seems that your configuration
is somewhat wrong as not all the required interfaces (VNET) are available
to the agent. You can check interfaces using "brctl show" command.

On Thu, Jan 11, 2018 at 4:06 AM Dickson Lam (dilam)  wrote:

> Hi Jagdish/Gregoire:
>
> Enclosed please find the log files. I also change the log level to DEBUG
> too.
>
> Thanks
> Dickson
>
>