Re: problem with vm volume resize

[ilya]

device 0 implies root disk..

On 4/19/16 9:26 PM, Simon Weller wrote:
> Chris,
> 
> Device 0, if I'm not mistaken, normally refers to the root volume. Have you 
> tried this via the api directly, or via cloudmonkey to eliminate the ui?
> 
> - Si
> 
> Simon Weller/ENA
> (615) 312-6068
> 
> -Original Message-
> From: Chris Chupela [cchup...@dsscorp.com]
> Received: Tuesday, 19 Apr 2016, 10:57PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: problem with vm volume resize
> 
> I have a cloudstack 4.2 installation with vmware 5.0 as the underlying 
> hypervisor. I've resized volumes in the past using the web UI, but have run 
> into an issue where my resize attempt on an existing win2k8 data volume 
> failed. It is a resize from 50Gb to 100Gb, and I have enough storage to do 
> the resize.
> 
> When I attempt the resize, the UI returns 'unable to resize volume', and I 
> find the following error in the management server log:
> 
> 2016-04-19 22:52:45,468 ERROR [vmware.resource.VmwareResource] 
> (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: 
> ResizeVolumeCommand) Unable to resize volume
> java.lang.RuntimeException: Invalid operation for device '0'.
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:413)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:862)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:691)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:572)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
>  Source)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> 
> The vm in question has been in the cloud enviornment/production for 2+ years. 
> It has a root volume, and 3 data volumes. I'm trying to resize the first data 
> volume.
> 
> I've seen some mention of issues like this with resizing volumes that were 
> created from snapshots, but that doesn't apply here.
> 
> Any thoughts on why my resize attempt is failing?
> 
> Chris Chupela
> Systems Engineer
> DSS
> 610.927.2031 Office
> 610.334.2392 Cell
> 
> Website | Data Center 
> | Twitter | 
> Facebook
> 
> 

Re: problem with vm volume resize

[ilya]

I was under impression root disk resize was only supported in KVM.

On 4/19/16 9:26 PM, Simon Weller wrote:
> Chris,
> 
> Device 0, if I'm not mistaken, normally refers to the root volume. Have you 
> tried this via the api directly, or via cloudmonkey to eliminate the ui?
> 
> - Si
> 
> Simon Weller/ENA
> (615) 312-6068
> 
> -Original Message-
> From: Chris Chupela [cchup...@dsscorp.com]
> Received: Tuesday, 19 Apr 2016, 10:57PM
> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
> Subject: problem with vm volume resize
> 
> I have a cloudstack 4.2 installation with vmware 5.0 as the underlying 
> hypervisor. I've resized volumes in the past using the web UI, but have run 
> into an issue where my resize attempt on an existing win2k8 data volume 
> failed. It is a resize from 50Gb to 100Gb, and I have enough storage to do 
> the resize.
> 
> When I attempt the resize, the UI returns 'unable to resize volume', and I 
> find the following error in the management server log:
> 
> 2016-04-19 22:52:45,468 ERROR [vmware.resource.VmwareResource] 
> (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: 
> ResizeVolumeCommand) Unable to resize volume
> java.lang.RuntimeException: Invalid operation for device '0'.
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:413)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:862)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:691)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:572)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
>  Source)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
>  Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> 
> The vm in question has been in the cloud enviornment/production for 2+ years. 
> It has a root volume, and 3 data volumes. I'm trying to resize the first data 
> volume.
> 
> I've seen some mention of issues like this with resizing volumes that were 
> created from snapshots, but that doesn't apply here.
> 
> Any thoughts on why my resize attempt is failing?
> 
> Chris Chupela
> Systems Engineer
> DSS
> 610.927.2031 Office
> 610.334.2392 Cell
> 
> Website | Data Center 
> | Twitter | 
> Facebook
> 
> 

Re: Bug in Snapshot Retention?

[Anshul Gangwar]

Are you getting any exception in logs after the completion of snapshot for this 
volume?

 If so try changing “job.cancel.threshold” global setting to appropriate 
timeout. This will make sure that job is not completed before the snapshot 
process is finished and will also make sure that cleanup process is not 
failing. This setting will affect all the jobs.

Regards,
Anshul



> On 20-Apr-2016, at 6:24 AM, Sean Lair  wrote:
> 
> Hi all,
> 
> I'm running Cloudstack 4.8 on XenServer 6.5.   I have one volume that I'm 
> taking snapshots of, it is set to keep a total of 29 snapshots, but I have 
> close to 100 snapshots in the state of "BackedUp".  Am I misinterpreting the 
> scheduled snapshot screen or am I running into a bug?  Please see the output 
> below for more detail:
> 
> [cid:image004.jpg@01D19A75.2310A6C0]
> 
> MariaDB [cloud]> select count(status) from snapshots where volume_id = 71 and 
> status = 'backedup';
> +---+
> | count(status) |
> +---+
> |98 |
> +---+
> 1 row in set (0.00 sec)
> 
> Thanks
> Sean
> 




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Bug in Snapshot Retention?

[Shweta Agarwal]

Hi Sean,
Can you also Check Removed field for these snapshots in snapshots table

Thanks
Shweta
Principal Product Engineer, CloudPlatform
Accelerite


From: Sean Lair 
Sent: Wednesday, April 20, 2016 6:24 AM
To: users@cloudstack.apache.org
Subject: Bug in Snapshot Retention?

Hi all,

I'm running Cloudstack 4.8 on XenServer 6.5.   I have one volume that I'm 
taking snapshots of, it is set to keep a total of 29 snapshots, but I have 
close to 100 snapshots in the state of "BackedUp".  Am I misinterpreting the 
scheduled snapshot screen or am I running into a bug?  Please see the output 
below for more detail:

[cid:image004.jpg@01D19A75.2310A6C0]

MariaDB [cloud]> select count(status) from snapshots where volume_id = 71 and 
status = 'backedup';
+---+
| count(status) |
+---+
|98 |
+---+
1 row in set (0.00 sec)

Thanks
Sean




DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

RE: problem with vm volume resize

[Simon Weller]

Chris,

Device 0, if I'm not mistaken, normally refers to the root volume. Have you 
tried this via the api directly, or via cloudmonkey to eliminate the ui?

- Si

Simon Weller/ENA
(615) 312-6068

-Original Message-
From: Chris Chupela [cchup...@dsscorp.com]
Received: Tuesday, 19 Apr 2016, 10:57PM
To: users@cloudstack.apache.org [users@cloudstack.apache.org]
Subject: problem with vm volume resize

I have a cloudstack 4.2 installation with vmware 5.0 as the underlying 
hypervisor. I've resized volumes in the past using the web UI, but have run 
into an issue where my resize attempt on an existing win2k8 data volume failed. 
It is a resize from 50Gb to 100Gb, and I have enough storage to do the resize.

When I attempt the resize, the UI returns 'unable to resize volume', and I find 
the following error in the management server log:

2016-04-19 22:52:45,468 ERROR [vmware.resource.VmwareResource] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Unable to resize volume
java.lang.RuntimeException: Invalid operation for device '0'.
at 
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:413)
at 
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:862)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:691)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:572)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
 Source)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
 Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The vm in question has been in the cloud enviornment/production for 2+ years. 
It has a root volume, and 3 data volumes. I'm trying to resize the first data 
volume.

I've seen some mention of issues like this with resizing volumes that were 
created from snapshots, but that doesn't apply here.

Any thoughts on why my resize attempt is failing?

Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | 
Twitter | 
Facebook

problem with vm volume resize

[Chris Chupela]

I have a cloudstack 4.2 installation with vmware 5.0 as the underlying 
hypervisor. I've resized volumes in the past using the web UI, but have run 
into an issue where my resize attempt on an existing win2k8 data volume failed. 
It is a resize from 50Gb to 100Gb, and I have enough storage to do the resize.

When I attempt the resize, the UI returns 'unable to resize volume', and I find 
the following error in the management server log:

2016-04-19 22:52:45,468 ERROR [vmware.resource.VmwareResource] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Unable to resize volume
java.lang.RuntimeException: Invalid operation for device '0'.
at 
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:413)
at 
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:862)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:691)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:572)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
 Source)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
 Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

The vm in question has been in the cloud enviornment/production for 2+ years. 
It has a root volume, and 3 data volumes. I'm trying to resize the first data 
volume.

I've seen some mention of issues like this with resizing volumes that were 
created from snapshots, but that doesn't apply here.

Any thoughts on why my resize attempt is failing?

Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | 
Twitter | 
Facebook

Bug in Snapshot Retention?

[Sean Lair]

Hi all,

I'm running Cloudstack 4.8 on XenServer 6.5.   I have one volume that I'm 
taking snapshots of, it is set to keep a total of 29 snapshots, but I have 
close to 100 snapshots in the state of "BackedUp".  Am I misinterpreting the 
scheduled snapshot screen or am I running into a bug?  Please see the output 
below for more detail:

[cid:image004.jpg@01D19A75.2310A6C0]

MariaDB [cloud]> select count(status) from snapshots where volume_id = 71 and 
status = 'backedup';
+---+
| count(status) |
+---+
|98 |
+---+
1 row in set (0.00 sec)

Thanks
Sean

RE: Guid is not updated for cluster with specified cluster id

[Kirk Kosinski]

Hi, Mario.  What version of CloudStack is this?  Also, can you be more specific 
about what was done?  Did you reinstall the agent on the hosts, or change any 
of the agent configuration (e.g. agent.properties)?  

When you re-added artkvm2, did you add it to a new or existing cluster?  If it 
already existed, were there any other hosts in the cluster besides artkvm2?

Did you try any troubleshooting steps from the posts you found (if so, what did 
you try)?  

Lastly, please provide the entries for the affected cluster in the cluster and 
cluster_details tables.  Thanks!


Regards,

Kirk Kosinski

kirk.kosin...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HS
@shapeblue

-Original Message-
From: Mario Giammarco [mailto:mgiamma...@gmail.com] 
Sent: Friday, April 15, 2016 3:09 AM
To: users@cloudstack.apache.org
Subject: Guid is not updated for cluster with specified cluster id

Hello,
I had to delete and insert again two servers in a zone.
Now I was able to insert again the server artkvm2 with ip 10.4.1.3 but when I 
try to add again artkvm1 with ip 10.4.1.2 I only get:

Guid is not updated for cluster with specified cluster id; need to wait for 
hosts in this cluster to come up

I have seen other post in the past about this error but they are not helpful 
for me.

Here is the log:

2016-04-15 12:05:11,671 DEBUG [c.c.a.m.AgentManagerImpl] (AgentManager-
Handler-3:null) (logid:) SeqA 22-1109: Processing Seq 22-1109:  { Cmd ,
MgmtId: -1, via: 22, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":
{"_proxyVmId":3773,"_loadInfo":"{\n  \"connections\": []\n}","wait":0}}] }
2016-04-15 12:05:11,679 DEBUG [c.c.a.m.AgentManagerImpl] (AgentManager-
Handler-3:null) (logid:) SeqA 22-1109: Sending Seq 22-1109:  { Ans: ,
MgmtId: 345041274374, via: 22, Ver: v1, Flags: 100010, 
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2016-04-15 12:05:15,955 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-
47e15670) (logid:4d7b1671) ===START===  10.1.0.38 -- POST 
command=addHost=json
2016-04-15 12:05:15,966 WARN  [c.c.a.d.ParamGenericValidationWorker]
(catalina-exec-7:ctx-47e15670 ctx-e6b00129) (logid:4d7b1671) Received unknown 
parameters for command addHost. Unknown parameters : clustertype
2016-04-15 12:05:15,970 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-
47e15670 ctx-e6b00129) (logid:4d7b1671) unhandled exception executing api
command: [Ljava.lang.String;@59a74e3e
com.cloud.utils.exception.CloudRuntimeException: Guid is not updated for 
cluster with specified cluster id; need to wait for hosts in this cluster to 
come up
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.ja
va:588)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:5
7)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
l.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(Aop
Utils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoin
t(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflec
tiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(Expo
seInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Reflec
tiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopPr
oxy.java:204)
at com.sun.proxy.$Proxy157.discoverHosts(Unknown Source)
at
org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.
java:142)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:698)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:297)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(Def
aultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithCo
ntext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithCon
text(DefaultManagedContext.java:53)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
at com.cloud.api.ApiServlet.doPost(ApiServlet.java:91)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:643)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio

Fwd: Advice for community participation to lower tension

[Erik Weber]

This was recently sent to ComDev (d...@community.apache.org) and I feel it
is worth sharing.

Cheers,
Erik

-- Forwarded message --
From: Niclas Hedhman 
Date: Sat, Apr 9, 2016 at 3:50 AM
Subject: Advice for community participation to lower tension
To: d...@community.apache.org


Everyone,
recently there was some tension/friction in a community, and I posted the
following advice to everyone to better get along. Not only did the
community members responded positively, but I also got pinged privately to
make this available publicly, so here it is, and I will let the wider
community do with it what it sees fit...


First a few general guidelines;
  a. Assume that the other party agrees more than disagrees with you. We
tend to leave out agreements and focus on differences. Sometime this is
forgotten and escalation becomes absurd for no rational reason.

  b. When in doubt, assume that you are interpreting the message wrongly
and kindly ask for verification that you understood a particular topic well.

  c. When writing, assume that every sentence will be misinterpreted.
Review and try to reformulate to be as clear as possible.

  d. Use a submissive tone in all writing. Instead of the strong "In my
opinion, we must..." or the quite neutral "I think we should...", try to
use "Maybe we should consider..." or "Another idea that we could..."

   e. If you disagree strongly with an email sent, tag it Important, then
put it aside. Read it half a day later again. Put it aside. Read it again
next day, and then it is easier to write a balanced and inviting response,
instead of the initial vitriol that flows through us when we get upset. I
found that sometimes a response wouldn't be necessary, as the importance
was actually much lower than originally perceived, and I would be able to
work "with", instead of "against", a given change.

  f. Be forgiving and accept different priorities. The other person is not
out to get you or attack your work. More often than not, it is one of the
above (a-d) that are failing, or that the other person prioritize some
aspect higher than you do. Sometimes, this requires compromises, sometimes
not and the different priorities can co-exist.


Most communities at Apache consists of level-headed, reasonable people, who
have a strong vested interest in its Apache project. This interest, often
passion, is both the source of tension, but it is also what unites the
people within the community. It is easy to forget the vast amount of
agreement that exists, and get upset over relatively small disagreements.
Ability to put that aside, or downplay the importance, will ensure a
harmonious project.

Face-to-Face is excellent way to eliminate disagreements, but that is often
not practical. Consider Skype or Google Hangout, just for the social aspect
of being part of this community. It should not be formal, and the
invitation should go out to everyone, perhaps someone want to make a short
presentation of what he/she is doing, to have some "structure", but that
might not be needed either. Once we have a face to the words, and a general
idea how that person is socially, we are much more capable to interact by
email.


Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: CloudStack Logging

[Simon Weller]

Paul,

Are you wanting for focus on logs on releases later than a particular version 
(e.g. 4.6)?

- Si

From: Paul Angus 
Sent: Tuesday, April 19, 2016 10:55 AM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: RE: CloudStack Logging

No problem.

Good question - Any and all logs.  Often, it's the mundane stuff which obscures 
the messages that you really need to see!


Kind regards,

Paul Angus

Regards,

Paul Angus

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

-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: 19 April 2016 16:53
To: d...@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: CloudStack Logging

Thanks Paul.  Are you looking for only logs with errors or are you just looking 
for just any management server logs?

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_

On Tue, Apr 19, 2016 at 11:45 AM, Paul Angus 
wrote:

> Thanks Will,
>
> As far as I know anything sensitive is removed or obfuscated (vcenter
> password displayed as h**).  IP addresses and hostnames are shown.
> Users may want to use a tool like SED to replace IP addresses or
> internal domain names
>
> http://forums.qrz.com/index.php?threads/remove-ip-addresses-from-log-f
> iles.204196/
>
>
> Kind regards,
>
> Paul Angus
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: 19 April 2016 16:40
> To: d...@cloudstack.apache.org
> Cc: users@cloudstack.apache.org
> Subject: Re: CloudStack Logging
>
> I like this initiative Paul.  I just wanted to check with you.  Do you
> know if there is any confidential information like credentials or the
> like that is logged in the management server log?  I thought we had
> done a push at one point to make sure no sensitive data was logged,
> but I don't remember for sure.  I think knowing the answer to this
> will help people feel more comfortable uploading logs.
>
> Thanks for the valuable initiative...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> @CloudOps_
>
> On Tue, Apr 19, 2016 at 11:34 AM, Paul Angus
> 
> wrote:
>
> > Hi All,
> >
> > I'm running an initiative to improve CloudStack logging.  I'm going
> > to be analysing logs and re-categorising the DEBUG, INFO, WARN and
> > ERROR where appropriate such that we can reduce the default logging
> > level to INFO without losing important troubleshooting information,
> > while at the same time making the management-server log far more
> > readable for operational admins.
> >
> > To achieve this I need logs to work with.
> >
> > Please could anyone interested upload logs to:
> > https://shapeblue.brickftp.com
> >
> > The logs will be treated in the strictest confidence and public
> > download of the logs will not be available.
> > I'm especially interested in logs which you found particularly
> > difficult to read or specific messages which you think are
> > misscategorised
> >
> > If you wish, put comments at the top of the logs or send a message
> > directly or via the mailing lists pointing out specific issues.
> > Please compress the logs!
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > Regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> >
>

RE: CloudStack Logging

[Paul Angus]

No problem.  

Good question - Any and all logs.  Often, it's the mundane stuff which obscures 
the messages that you really need to see!


Kind regards,

Paul Angus

Regards,

Paul Angus

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

-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: 19 April 2016 16:53
To: d...@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: CloudStack Logging

Thanks Paul.  Are you looking for only logs with errors or are you just looking 
for just any management server logs?

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_

On Tue, Apr 19, 2016 at 11:45 AM, Paul Angus 
wrote:

> Thanks Will,
>
> As far as I know anything sensitive is removed or obfuscated (vcenter 
> password displayed as h**).  IP addresses and hostnames are shown.
> Users may want to use a tool like SED to replace IP addresses or 
> internal domain names
>
> http://forums.qrz.com/index.php?threads/remove-ip-addresses-from-log-f
> iles.204196/
>
>
> Kind regards,
>
> Paul Angus
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On 
> Behalf Of Will Stevens
> Sent: 19 April 2016 16:40
> To: d...@cloudstack.apache.org
> Cc: users@cloudstack.apache.org
> Subject: Re: CloudStack Logging
>
> I like this initiative Paul.  I just wanted to check with you.  Do you 
> know if there is any confidential information like credentials or the 
> like that is logged in the management server log?  I thought we had 
> done a push at one point to make sure no sensitive data was logged, 
> but I don't remember for sure.  I think knowing the answer to this 
> will help people feel more comfortable uploading logs.
>
> Thanks for the valuable initiative...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw 
> @CloudOps_
>
> On Tue, Apr 19, 2016 at 11:34 AM, Paul Angus 
> 
> wrote:
>
> > Hi All,
> >
> > I'm running an initiative to improve CloudStack logging.  I'm going 
> > to be analysing logs and re-categorising the DEBUG, INFO, WARN and 
> > ERROR where appropriate such that we can reduce the default logging 
> > level to INFO without losing important troubleshooting information, 
> > while at the same time making the management-server log far more 
> > readable for operational admins.
> >
> > To achieve this I need logs to work with.
> >
> > Please could anyone interested upload logs to:
> > https://shapeblue.brickftp.com
> >
> > The logs will be treated in the strictest confidence and public 
> > download of the logs will not be available.
> > I'm especially interested in logs which you found particularly 
> > difficult to read or specific messages which you think are 
> > misscategorised
> >
> > If you wish, put comments at the top of the logs or send a message 
> > directly or via the mailing lists pointing out specific issues.
> > Please compress the logs!
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > Regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> >
>

Re: CloudStack Logging

[Will Stevens]

Thanks Paul.  Are you looking for only logs with errors or are you just
looking for just any management server logs?

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Tue, Apr 19, 2016 at 11:45 AM, Paul Angus 
wrote:

> Thanks Will,
>
> As far as I know anything sensitive is removed or obfuscated (vcenter
> password displayed as h**).  IP addresses and hostnames are shown.
> Users may want to use a tool like SED to replace IP addresses or internal
> domain names
>
> http://forums.qrz.com/index.php?threads/remove-ip-addresses-from-log-files.204196/
>
>
> Kind regards,
>
> Paul Angus
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: 19 April 2016 16:40
> To: d...@cloudstack.apache.org
> Cc: users@cloudstack.apache.org
> Subject: Re: CloudStack Logging
>
> I like this initiative Paul.  I just wanted to check with you.  Do you
> know if there is any confidential information like credentials or the like
> that is logged in the management server log?  I thought we had done a push
> at one point to make sure no sensitive data was logged, but I don't
> remember for sure.  I think knowing the answer to this will help people
> feel more comfortable uploading logs.
>
> Thanks for the valuable initiative...
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> @CloudOps_
>
> On Tue, Apr 19, 2016 at 11:34 AM, Paul Angus 
> wrote:
>
> > Hi All,
> >
> > I'm running an initiative to improve CloudStack logging.  I'm going to
> > be analysing logs and re-categorising the DEBUG, INFO, WARN and ERROR
> > where appropriate such that we can reduce the default logging level to
> > INFO without losing important troubleshooting information, while at
> > the same time making the management-server log far more readable for
> > operational admins.
> >
> > To achieve this I need logs to work with.
> >
> > Please could anyone interested upload logs to:
> > https://shapeblue.brickftp.com
> >
> > The logs will be treated in the strictest confidence and public
> > download of the logs will not be available.
> > I'm especially interested in logs which you found particularly
> > difficult to read or specific messages which you think are
> > misscategorised
> >
> > If you wish, put comments at the top of the logs or send a message
> > directly or via the mailing lists pointing out specific issues.
> > Please compress the logs!
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > Regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> >
>

RE: CloudStack Logging

[Paul Angus]

Thanks Will,

As far as I know anything sensitive is removed or obfuscated (vcenter password 
displayed as h**).  IP addresses and hostnames are shown.
Users may want to use a tool like SED to replace IP addresses or internal 
domain names
http://forums.qrz.com/index.php?threads/remove-ip-addresses-from-log-files.204196/


Kind regards,

Paul Angus

Regards,

Paul Angus

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

-Original Message-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of 
Will Stevens
Sent: 19 April 2016 16:40
To: d...@cloudstack.apache.org
Cc: users@cloudstack.apache.org
Subject: Re: CloudStack Logging

I like this initiative Paul.  I just wanted to check with you.  Do you know if 
there is any confidential information like credentials or the like that is 
logged in the management server log?  I thought we had done a push at one point 
to make sure no sensitive data was logged, but I don't remember for sure.  I 
think knowing the answer to this will help people feel more comfortable 
uploading logs.

Thanks for the valuable initiative...

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_

On Tue, Apr 19, 2016 at 11:34 AM, Paul Angus 
wrote:

> Hi All,
>
> I'm running an initiative to improve CloudStack logging.  I'm going to 
> be analysing logs and re-categorising the DEBUG, INFO, WARN and ERROR 
> where appropriate such that we can reduce the default logging level to 
> INFO without losing important troubleshooting information, while at 
> the same time making the management-server log far more readable for 
> operational admins.
>
> To achieve this I need logs to work with.
>
> Please could anyone interested upload logs to:
> https://shapeblue.brickftp.com
>
> The logs will be treated in the strictest confidence and public 
> download of the logs will not be available.
> I'm especially interested in logs which you found particularly 
> difficult to read or specific messages which you think are 
> misscategorised
>
> If you wish, put comments at the top of the logs or send a message 
> directly or via the mailing lists pointing out specific issues.
> Please compress the logs!
>
> Kind regards,
>
> Paul Angus
>
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>

Re: CloudStack Logging

[Will Stevens]

I like this initiative Paul.  I just wanted to check with you.  Do you know
if there is any confidential information like credentials or the like that
is logged in the management server log?  I thought we had done a push at
one point to make sure no sensitive data was logged, but I don't remember
for sure.  I think knowing the answer to this will help people feel more
comfortable uploading logs.

Thanks for the valuable initiative...

*Will STEVENS*
Lead Developer

*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Tue, Apr 19, 2016 at 11:34 AM, Paul Angus 
wrote:

> Hi All,
>
> I'm running an initiative to improve CloudStack logging.  I'm going to be
> analysing logs and re-categorising the DEBUG, INFO, WARN and ERROR where
> appropriate such that we can reduce the default logging level to INFO
> without losing important troubleshooting information, while at the same
> time making the management-server log far more readable for operational
> admins.
>
> To achieve this I need logs to work with.
>
> Please could anyone interested upload logs to:
> https://shapeblue.brickftp.com
>
> The logs will be treated in the strictest confidence and public download
> of the logs will not be available.
> I'm especially interested in logs which you found particularly difficult
> to read or specific messages which you think are misscategorised
>
> If you wish, put comments at the top of the logs or send a message
> directly or via the mailing lists pointing out specific issues.
> Please compress the logs!
>
> Kind regards,
>
> Paul Angus
>
>
> Regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>

CloudStack Logging

[Paul Angus]

Hi All,

I'm running an initiative to improve CloudStack logging.  I'm going to be 
analysing logs and re-categorising the DEBUG, INFO, WARN and ERROR where 
appropriate such that we can reduce the default logging level to INFO without 
losing important troubleshooting information, while at the same time making the 
management-server log far more readable for operational admins.

To achieve this I need logs to work with.

Please could anyone interested upload logs to:
https://shapeblue.brickftp.com

The logs will be treated in the strictest confidence and public download of the 
logs will not be available.
I'm especially interested in logs which you found particularly difficult to 
read or specific messages which you think are misscategorised

If you wish, put comments at the top of the logs or send a message directly or 
via the mailing lists pointing out specific issues.
Please compress the logs!

Kind regards,

Paul Angus


Regards,

Paul Angus

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

Re: Best way to update Templates

[ilya]

Sean,

You secondary storage should grow naturally - as you add more content.

Also, you would see the most benefit from link clones, when they are
used optimally. That is - you separate your DATA and ROOT into 2
distinctive disks.

I'm not going to bother you with explanation as i'm certain you know it
by now. I've just seen some folks use ROOT disk for both OS and Data -
and wonder why their disks are horrendously large.

Lastly, there is also an API call called recoverVM, which basically
would let you switch the underlying template from the VM, but preserve
the metadata - that is served by router vms. In essense IP, hstname and
metadata remains the same, but disk is reset to new pre-configured state

If you have a smart solution that on the OS start, see that OS is not
configured, fetches metadata from router vm, configures it self and
marks as configure complete (to avoid configuration on next reboot).
Basically makes a VM truly ephemeral. Then on your upgrade cycle, you
just issues recover VM api call in mass - and assuming your automation
is perfect - the VM will power on and configure itself as it was with
previous patch set.

This usually works much easier with Linux, i doubt windoows would be so
simple, but just a thought...

Regards
ilya

On 4/18/16 9:15 PM, Sean Lair wrote:
> Thanks for the reply Kirk.  Will it auto-delete templates if there are not 
> any VMs cloned from them?  Is there a better way to keep templates up-to-date 
> with patches?
> 
> We will be patching these templates fairly often as Microsoft releases new 
> patches.  It sounds like our secondary storage will grow quite quick if it 
> doesn't delete old templates, or if we have long-lived VMs that are linked to 
> these old templates.
> 
> This does explain why our secondary storage has grown more than we expected 
> lately.
> 
> Thanks for any help or guidance you can provide!
> 
> Sean
>  
> 
>> On Apr 18, 2016, at 7:24 PM, Kirk Kosinski  
>> wrote:
>>
>> Hi, yes that is a good way to do it.  Note that if you do delete a template 
>> that is in use, it won't actually be deleted on the back-end (i.e. the 
>> database entries will remain, as will the files on secondary storage), 
>> rather it is just hidden from the end-users in the UI and API.  Giving a new 
>> template the same name as a deleted one might be a bit confusing so you 
>> could consider adding a version number or date code.
>>
>> Best regards,
>>
>> Regards,
>>
>> Kirk Kosinski
>>
>> kirk.kosin...@shapeblue.com 
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HS
>> @shapeblue
>>
>> -Original Message-
>> From: Sean Lair [mailto:sl...@ippathways.com] 
>> Sent: Monday, April 18, 2016 3:09 PM
>> To: users@cloudstack.apache.org
>> Subject: Best way to update Templates
>>
>> Hello,
>>
>> We need to periodically update our templates, for example installing the 
>> latest Windows updates in our Windows Server templates  Is there a way to 
>> update existing templates or do we just need to delete the old template and 
>> create new one with the same name?
>>
>> The only issue I see with that so far is that we lose the linkage between 
>> instaces (VMs) and templates.
>>
>> Thanks
>> Sean
>>