RE: problem with vm volume resize [SOLVED]

[Chris Chupela]

The issue turned out to be that the backup software was attempting to backup 
the volume at the same time I was trying to resize it.  After making sure the 
backup wasn't running, I was able to resize the drive without issue.


Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | Twitter | Facebook

-Original Message-
From: Chris Chupela 
Sent: Wednesday, April 20, 2016 7:04 AM
To: users@cloudstack.apache.org
Subject: RE: problem with vm volume resize

The root disk resize isn't supported with vmware, but the disk I'm attempting 
to resize isn't a root disk. Based on what I've seen in the logs, the GUI, and 
in the vcenter properties for this instance, it appears the disk I'm attempting 
this on is identified correctly.  Disk 0:0 is the root, 0:1 is the first data 
disk, etc. It is this first data disk I'm attempting to resize. I've listed the 
rest of the log messages below, which show it running the command, finding the 
disk 0:1. Then the Java runtime error occurs. I haven't tried running the 
resize via cloudmonkey/api yet. I don't think its been vmotioned, but I'll have 
to check.


2016-04-19 22:52:45,001 DEBUG [agent.transport.Request] 
(AgentManager-Handler-3:null) Seq 39-717719634: Executing:  { Cmd , MgmtId: 
345052112145, via: 39, Ver: v1, Flags: 100011, 
[{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"path":"d4ef260d8182427a8b36fada13875278","pool":{"id":200,"uuid":"d01b5905-0cac-31b9-b25f-7b7641965829","host":"VMFS
 datastore: 
/WYO-DC1/WYO-P1-C1-PS1-ESX","path":"/WYO-DC1/WYO-P1-C1-PS1-ESX","port":0,"type":"VMFS"},"vmInstance":"i-27-387-VM","newSize":107374182400,"currentSize":53687091200,"shrinkOk":false,"wait":0}}]
 }

2016-04-19 22:52:45,001 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-88:null) Seq 39-717719634: Executing request
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Look for disk device info from volume : d4ef260d8182427a8b36fada13875278
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Test against disk device, controller key: 1000, unit number: 0
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Test against disk backing : [WYO-P1-C1-PS1-ESX] 
i-27-387-VM/2d51d2b060f84d12802b01b9b22098d8-01.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Test against disk backing : [WYO-P1-C1-PS1-ESX] 
i-27-387-VM/2d51d2b060f84d12802b01b9b22098d8.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Test against disk device, controller key: 1000, unit number: 1
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Test against disk backing : [WYO-P1-C1-PS1-ESX] 
i-27-387-VM/d4ef260d8182427a8b36fada13875278-01.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] 
(DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) 
Disk backing : [WYO-P1-C1-PS1-ESX] 
i-27-387-VM/d4ef260d8182427a8b36fada13875278-01.vmdk matches ==> scsi0:1



Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | Twitter | Facebook

-Original Message-
From: Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
Sent: Wednesday, April 20, 2016 4:28 AM
To: users@cloudstack.apache.org
Subject: Re: problem with vm volume resize

Chris - out of interest - has this VM been through a storage vMotion? We have 
come across an issue recently where a similar thing happened, the wrong disk 
was resized and our investigation so far shows this to potentially be caused by 
disks having been renamed during svMotion.


Dag Sonstebo






On 20/04/2016, 07:04, "Pavan Bandarupally"  
wrote:

>I think Root disk resize is supported only on KVM as per the FS 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Root+Resize+Supp
>ort
>
>
>-Original Message-
>From: ilya [mailto:ilya.mailing.li...@gmail.com]
>Sent: Wednesday, April 20, 2016 11:23 AM
>To: users@cloudstack.apache.org
>Subject: Re: problem with vm volume resize
>
>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]
>> 

Re: High importance Suggest backup tool

[Sebastian Gomez]

We use EMC VBA wich make an incremental for-ever backup at storage level.
It has an appliance that allows to restore the full VM or file level.
We have VMware as hypervisor, I don't know if there is support for
xenserver.
El 18/4/2016 16:03, "kotipalli venkatesh" 
escribió:

we are using NFS as a storage

On Mon, Apr 18, 2016 at 7:24 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> If you only want that, I would use a backup tool at the storage level. It
> is pretty straight forward.
>
> I do not know what type of storage you are using, but if you have
something
> over NFS+LVM, you can easily use backup tools for LVM.
>
> On Mon, Apr 18, 2016 at 10:52 AM, kotipalli venkatesh <
> venkateshcloudt...@gmail.com> wrote:
>
> > Yes, Please suggest third-party backup tool. we are using xenserver 6.2
> as
> > a hyper-visor and cloudstack version 4.5 version.
> >
> > what is the best compatibility of the our CS environment.
> >
> >
> > On Mon, Apr 18, 2016 at 7:04 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Ok,
> > > So, you want continuos backup of VHDs?
> > >
> > > On Mon, Apr 18, 2016 at 10:29 AM, kotipalli venkatesh <
> > > venkateshcloudt...@gmail.com> wrote:
> > >
> > > > Hi Rafael,
> > > >
> > > > Thnx for your reply.
> > > >
> > > > Yes, we are looking os+file (Completely previous state ) level
> backup.
> > > > Suppose VM is crashed unexpectedly (WINDOWS/LINUX).we are using that
> > > backup
> > > > spin a new VM using previous day backup.
> > > >
> > > > Regards,
> > > > Venkatesh.k
> > > >
> > > > On Mon, Apr 18, 2016 at 5:43 PM, Rafael Weingärtner <
> > > > rafaelweingart...@gmail.com> wrote:
> > > >
> > > > > What do you mean by backup at the OS level?
> > > > >
> > > > > Backup through the hypervisor or OS of the VM?
> > > > >
> > > > > On Mon, Apr 18, 2016 at 8:50 AM, kotipalli venkatesh <
> > > > > venkateshcloudt...@gmail.com> wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I am using cloud stack version 4.5.0
> > > > > > Hypervisor  XenServer 6.2
> > > > > >
> > > > > > we need full backups in the OS level by using any third party
> tool.
> > > > > >
> > > > > > can some one please suggest any third party tool with support.
> > > > > >
> > > > > > Regards,
> > > > > > Venkatesh.k
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Rafael Weingärtner
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

Issues with Devcloud4

[Chaz PC]

Hello, 
I am facing an issue with Devcloud4, if the jetty server is stopped and then I 
run it again the system vm agent status is set as disconnected and then blank. 
I don't understand what is the issue, if it was working before why it is not 
working after restarting the jetty server. 
It seems as if it is not connecting to the secondary storage or some times I 
receive error messages stating that the storage is insufficient. What would be 
the cause?
Best regards Hanan 

Re: Error: "Unable to add host"

[Cayetano Rodríguez]

It wasn't enabled but I enabled the virtualization in the BIOS and I still
can't add a host

El lunes, 18 de abril de 2016, Pavan Bandarupally <
pavan.bandarupa...@accelerite.com> escribió:

> Is Virtualization enabled in the BIOS for the machine ?
>
> -Original Message-
> From: Cayetano Rodríguez [mailto:tfg.cloudcomput...@gmail.com
> ]
> Sent: Friday, April 15, 2016 8:05 PM
> To: users@cloudstack.apache.org 
> Subject: Re: Error: "Unable to add host"
>
> Yes, I'm trying to setup everything on a single machine. I followed that
> guide and now I've checked all steps in the KVM section. When I execute  "
> lsmod | grep kvm "
>  I get the following output:
> [root@srvr1 ~]# lsmod | grep kvm
> kvm   341551  0
>
> In the guide it appears in the output another line (kvm_intel), am I doing
> something wrong so that line doesn't appear?
>
> Thank you
>
> 2016-04-15 4:06 GMT+02:00 Pavan Bandarupally <
> pavan.bandarupa...@accelerite.com >:
>
> > If you have resources, it is recommended to have management server and
> > host on separate machines. But just to troubleshoot your environment
> > you can check the below link and see if things work.
> >
> > From my understanding you are trying to setup everything ( management
> > server and hotst) on a single machine. The error you face is generally
> > seen if the hypervisor host doesn't have KVM agent installed properly
> > (I might be wrong here). Can you please go through the below link and
> > make sure that you have followed all the required steps (for KVM
> > installation ) and confirm if KVM is properly installed (say by checking
> lsmod | grep kvm ) ?
> >
> >
> > http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/
> > 4.6/qig.html
> >
> > Regards,
> > Pavan
> >
> >
> > -Original Message-
> > From: Cayetano Rodríguez [mailto:tfg.cloudcomput...@gmail.com
> ]
> > Sent: Friday, April 15, 2016 6:08 AM
> > To: users@cloudstack.apache.org 
> > Subject: Re: Error: "Unable to add host"
> >
> > The managenent ip address is the same as the host ip address, and the
> > same as the machine that I'm using...
> > I've done this because I've followed the Quick Installation Guide that
> > is focused on doing everything in the same machine, and this guide
> > specifies to use the same ip addresses in managenent server and the
> first host.
> >
> > I am interested in getting started on CloudStack doing this "trial"
> > installation, so I don't need lots of resources (and actually don't
> > have them at this moment). For this reason I think doing everything in
> > the same machine is the best option for me.
> >
> > If you could help me doing this that would be great, or if it's not
> > possible and you think it's better and easier separating the
> > management server and host, I could look for another machine to use.
> >
> > Thank you very much.
> >
> > El jueves, 14 de abril de 2016, Simon Weller  > escribió:
> >
> > > Can you ping the ip address you supplied from the management server?
> > > Are you able to ssh into it using the credentials (from the
> > > management
> > > server) you're using in the Cloudstack GUI?
> > >
> > > ICloudstack is really designed to be deployed on separate servers,
> > > so mixing management and hosts can complicate things a fair bit.
> > >
> > > - Si
> > >
> > >
> > > 
> > > From: Cayetano Rodríguez 
> > > >
> > > Sent: Thursday, April 14, 2016 12:18 PM
> > > To: users@cloudstack.apache.org  
> > > Subject: Error: "Unable to add host"
> > >
> > > Hi everyone!
> > >
> > > I've followed the "Quick Installation Guide for Centos 6" guide, to
> > > install CloudStack in one machine with Centos 6.5. I've followed all
> > > steps and finished installing, but I get an error while configuring
> > > it. The error appears when CloudStack is trying to add a host. The
> > > error says: "Unable to add the host".
> > >
> > > I've checked /var/log/cloudstack/management/management-server.log
> > > and this is the complete error:
> > >
> > >
> > >
> > > 2016-04-14 19:10:36,257 DEBUG [c.c.a.ApiServlet]
> > > (catalina-exec-1:ctx-3c617426) (logid:25f4748e) ===START===
> > > 192.168.1.2 -- GET
> > >
> > > command=listNetworkOfferings=Enabled=Shared
> > > se
> > > =json&_=1460653836254
> > > 2016-04-14 19:10:36,315 DEBUG [c.c.a.ApiServlet]
> > > (catalina-exec-1:ctx-3c617426 ctx-5090361b) (logid:25f4748e)
> > > ===END===
> > > 192.168.1.2 -- GET
> > >
> > > command=listNetworkOfferings=Enabled=Shared
> > > se
> > > =json&_=1460653836254
> > > 2016-04-14 19:10:36,323 DEBUG [c.c.a.ApiServlet]
> > > (catalina-exec-14:ctx-8f5ed97e) (logid:30b82c99) ===START===
> > > 192.168.1.2
> > > -- POST  command=addHost=json
> > > 2016-04-14 19:10:36,335 WARN  [c.c.a.d.ParamGenericValidationWorker]
> > > 

Re: Unable to start a HVM VM with more than 2 volumes attached using XenServer 6.5 and ACS 4.7.1

[Koushik Das]

Once the VM is in running state, is "allowed devices" showing proper list? 
After that if auto detect is working properly then maybe the issue is somewhere 
else.

-Koushik


From: Simon Godard 
Sent: Thursday, April 21, 2016 12:41 AM
To: CloudStack Users Mailing list
Subject: Re: Unable to start a HVM VM with more than 2 volumes attached using 
XenServer 6.5 and ACS 4.7.1

After more investigation, I can confirm that the problem is only for HVM. I 
tried with a PV vm and everything is fine.

For some reason, performing the call: VM.get_allowed_VBD_devices on a HVM while 
the VM is still in starting state only returns a subset of device Ids: [1, 2] 
instead of [1,2,3,…,15] on PV. The logic then reverts to ‘autodetect’ which 
also seems invalid for a HVM VM.

--
Simon

> On Apr 20, 2016, at 08:20, Simon Godard  wrote:
>
> Hi,
>
> We are getting a weird error when trying to start a VM (based on a HVM 
> template) when attaching more than 2 volumes. We are using XenServer 6.5 and 
> CloudStack 4.7.1. Here are the logs:
>
> ACS
> Unable to start i-152-612-VM due to
> The device name is invalid
> at com.xensource.xenapi.Types.checkResponse(Types.java:1169)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:395)
> at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:457)
> at com.xensource.xenapi.VBD.create(VBD.java:322)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.createVbd(CitrixResourceBase.java:1148)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:119)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixStartCommandWrapper.execute(CitrixStartCommandWrapper.java:53)
> at 
> com.cloud.hypervisor.xenserver.resource.wrapper.xenbase.CitrixRequestWrapper.execute(CitrixRequestWrapper.java:122)
> at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:1678)
>
> XenServer
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3c596e35d366|audit] VBD.create: VM = 
> '23da57b8-cc94-3edd-66af-97397c1e9f89 (i-152-614-VM)'; VDI = 'invalid'
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3c596e35d366|xapi] Checking whether there's a migrate in 
> progress...
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3c596e35d366|xapi] VBD.create (device = 3; uuid = 
> d32bd2fb-68d9-a20b-3632-43c5cffd5ca1; ref = 
> OpaqueRef:d5d36ea6-2b79-2efd-c2ad-27403ffbdbf8)
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18677027 UNIX 
> /var/xapi/xapi||dummytaskhelper] task dispatch:SR.get_other_config 
> D:764bb880e1f7 created by task D:9e603ca8e24b
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18677028 UNIX 
> /var/xapi/xapi||dummytaskhelper] task dispatch:SR.get_sm_config 
> D:b30be613f286 created by task D:9e603ca8e24b
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VM.get_allowed_VBD_devices D:65d1aeb0e377|audit] 
> VM.get_allowed_VBD_devices: VM = '23da57b8-cc94-3edd-66af-97397c1e9f89 
> (i-152-614-VM)'
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:f5513cd51b7d|audit] VBD.create: VM = 
> '23da57b8-cc94-3edd-66af-97397c1e9f89 (i-152-614-VM)'; VDI = 
> '7c882c4f-eaed-49c9-952d-53f2db998ecd'
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:f5513cd51b7d|xapi] Checking whether there's a migrate in 
> progress...
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:f5513cd51b7d|xapi] VBD.create (device = 2; uuid = 
> b83f771a-c796-8f5b-26de-fb648327e305; ref = 
> OpaqueRef:f147-8d60-52b6-8041-72cf95fa7f44)
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VM.get_allowed_VBD_devices D:c180118513de|audit] 
> VM.get_allowed_VBD_devices: VM = '23da57b8-cc94-3edd-66af-97397c1e9f89 
> (i-152-614-VM)'
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3a50f805fbb1|audit] VBD.create: VM = 
> '23da57b8-cc94-3edd-66af-97397c1e9f89 (i-152-614-VM)'; VDI = 
> '78ab2cc5-a7ec-4709-9556-a1d6bfbc2b65'
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3a50f805fbb1|xapi] Checking whether there's a migrate in 
> progress...
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VBD.create R:3a50f805fbb1|xapi] VBD.create (device = 1; uuid = 
> 6556fa97-356f-65ec-fcda-d41205804b46; ref = 
> OpaqueRef:c71b9afd-7069-5caf-f67b-befc83de722b)
> Apr 19 14:00:33 cca-t2-xen01 xapi: [debug|cca-t2-xen01|18676540 INET 
> :::80|VM.get_allowed_VBD_devices 

Re: CloudStack Logging

[Daan Hoogland]

On Thu, Apr 21, 2016 at 9:49 AM, Paul Angus 
wrote:

> Hey Daan,
>
> I understand from a purists point of view, but to me messages like:
>
> INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-113:ctx-56d9f9f2)
> Scan hung worker VM to recycle
>
> Are part of the inner workings of cloudstack, and only a developer is
> going to do anything with this information.
> Unless we can add another category like INFO-INTERNAL between DEBUG and
> INFO, a message like this is probably technically INFO, from anyone's
> practical point of view, its DEBUG.
>
​
There is nothing purist about it. ACS is freeing resources which is a
process taking resources. It is information important to an operator, maybe
not every operator has a process using every bit of information. That
doesn't mean it is not important. On one hand, you can always filter it in
your monitoring or searching. On the other hand, if it doesn't mean
anything to you it might mean that the phrasing is bad and should improve.
​

-- 
Daan

RE: CloudStack Logging

[Paul Angus]

Hi Frank,

'thinking out loud' - ideally I'd like to see this failure (and it reasons) 
surfaced to the admins outside of the logs.  Off the top of my head - a 
(helpful) detailed event/alert notification.

More helpful  info in the message (ie not 'host 24') *should* be pretty simple. 
 I'll have a look and ask one of our developers to help me with the actual 
code, once I've tracked it down.



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: Frank Louwers [mailto:fr...@openminds.be] 
Sent: 21 April 2016 08:14
To: users@cloudstack.apache.org
Subject: Re: CloudStack Logging

Hi Paul,

I’d love to see improvement in that area! Especially for my operational admins, 
the biggest issue we face is this:

- Someone wants to deploy a new VM, and it fails.

- Currently, it’s very hard to figure out exactly why. The best they get is 
“Capacity Planner failure”.

- They come to me :)


I think these failures are quite an easy use-case to improve logging on. If a 
VM can’t be started because of a “capacity” issue, it would we good to log (in 
a non-debug, non-info log):

- Which hosts were considered for CPU/Mem (based on zone, tags etc) (list them 
by name pref, not by “host 24” which means nothing to them as that number isn’t 
anywhere in the CS UI)

- Which of those considered hosts have the capacity needed (and for those that 
are excluded, weather they are excluded for RAM or CPU reasons)

- Exact same for Storage Pools

This would solve over 95% of my “Frank, I can’t find out why this VM won’t 
deploy” logging issues.

Regards,

Frank


> On 20 Apr 2016, at 22:05, Paul Angus  wrote:
> 
> Hi,
> 
> I don't think that it's a question of importance. INFO vs DEBUG should be 
> telling you different things. ERROR and WARN are also quite different.
> In general I'm targeting the cloud operational admins, the people who need to 
> know the health of their cloud and deal with issues as they're constantly 
> reading the log.
> 
> However, I'm not proposing to add or remove any messages, just revisit the 
> categorisation. If the 'operator' has their logging on debug they'd actually 
> see the same messages. The idea is to make turning the logging down to INFO 
> feasible.
> 
> You'd turn the logging back up to pick up code issues rather than just 
> operational issues.
> 
> Some VERY simplified definitions might be:
> 
> DEBUG:  inner workings of CloudStack that only a developer can 'understand'
> INFO:  actions that CloudStack is performing or information analysis (host 5 
> is full so not going to use it).
> WARN: this isn't good
> ERROR: something just didn't work.
> 
> 
> Grabbing a couple of examples
> 
> these should be debug - I can't 'do' anything with this information.
> 
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) Begin cleanup expired 
> async-jobs INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) End cleanup expired async-jobs 
> INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-2:ctx-3209f65c) 
> Scan hung worker VM to recycle INFO  [c.c.h.v.r.VmwareResource] 
> (DirectAgentCronJob-113:ctx-56d9f9f2) Scan hung worker VM to recycle
> 
> Whereas this should be WARN. I wouldn't want to lose this by switching 
> off DEBUG
> 
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-91226be7) 
> Detected management node left, id:2, nodeIP:10.2.0.6 DEBUG 
> [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-0bccd078) Detected 
> management node left, id:2, nodeIP:10.2.0.6
> 
> 
> 
> 
> 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: Chaz PC [mailto:dreeems4e...@hotmail.com]
> Sent: 20 April 2016 11:32
> To: users@cloudstack.apache.org
> Subject: RE: CloudStack Logging
> 
> Hello,
> I have a question what is the criteria that you are going to follow to decide 
> the log record importance. Who is the user that you will design the logging 
> process for. Is it for finding issues with the installation or is it for 
> security breaches or auditing.
> These questions are good to put in mind when designing the logging process.
> 
> 
> Sent from my Samsung Galaxy smartphone. 
>  Original message 
> From: Paul Angus  
> Date: 20/04/2016  1:01 PM  (GMT+04:00) To: 
> d...@cloudstack.apache.org, users@cloudstack.apache.org 
> Subject: RE: CloudStack Logging   Hi 
> Simon,
> 
> My gut says that it's probably not worth going back before 4.3.  There have 
> been large changes since then but I think that it's better to get as much 
> data as possible, limiting to 4.6+ might not give a particularly large 
> install base.
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> Regards,
> 
> Paul 

RE: CloudStack Logging

[Paul Angus]

Hey Daan,

I understand from a purists point of view, but to me messages like: 

INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-113:ctx-56d9f9f2) Scan 
hung worker VM to recycle

Are part of the inner workings of cloudstack, and only a developer is going to 
do anything with this information.
Unless we can add another category like INFO-INTERNAL between DEBUG and INFO, a 
message like this is probably technically INFO, from anyone's practical point 
of view, its DEBUG.



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: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: 20 April 2016 23:12
To: users@cloudstack.apache.org
Subject: Re: CloudStack Logging

Paul,
Your classification of levels seems right. I wouldn't say WARN means it isn't 
good but just that it might be given an objective the user might have. There is 
also FATAL, ERROR would be recoverable while FATAL means the system can no 
longer be trusted to do it's job right.

The INFO examples you are giving are indeed INFO as far as I'm concerned and 
not debug; ACS is reporting what it is doing on a pretty high level.
But we can discuss about it and even after we give proper levels to messages we 
can still decide to set levels for certain parts of the sys higher or lower 
then for others.


On Wed, Apr 20, 2016 at 10:05 PM, Paul Angus 
wrote:

> Hi,
>
> I don't think that it's a question of importance. INFO vs DEBUG should 
> be telling you different things. ERROR and WARN are also quite different.
> In general I'm targeting the cloud operational admins, the people who 
> need to know the health of their cloud and deal with issues as they're 
> constantly reading the log.
>
> However, I'm not proposing to add or remove any messages, just revisit 
> the categorisation. If the 'operator' has their logging on debug 
> they'd actually see the same messages. The idea is to make turning the 
> logging down to INFO feasible.
>
> You'd turn the logging back up to pick up code issues rather than just 
> operational issues.
>
> Some VERY simplified definitions might be:
>
> DEBUG:  inner workings of CloudStack that only a developer can 'understand'
> INFO:  actions that CloudStack is performing or information analysis 
> (host
> 5 is full so not going to use it).
> WARN: this isn't good
> ERROR: something just didn't work.
>
>
> Grabbing a couple of examples
>
> these should be debug - I can't 'do' anything with this information.
>
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) Begin cleanup expired 
> async-jobs INFO  [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) End cleanup expired async-jobs 
> INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-2:ctx-3209f65c) 
> Scan hung worker VM to recycle INFO  [c.c.h.v.r.VmwareResource] 
> (DirectAgentCronJob-113:ctx-56d9f9f2)
> Scan hung worker VM to recycle
>
> Whereas this should be WARN. I wouldn't want to lose this by switching 
> off DEBUG
>
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-91226be7)
> Detected management node left, id:2, nodeIP:10.2.0.6 DEBUG 
> [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-0bccd078)
> Detected management node left, id:2, nodeIP:10.2.0.6
>
>
>
>
> 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: Chaz PC [mailto:dreeems4e...@hotmail.com]
> Sent: 20 April 2016 11:32
> To: users@cloudstack.apache.org
> Subject: RE: CloudStack Logging
>
> Hello,
> I have a question what is the criteria that you are going to follow to 
> decide the log record importance. Who is the user that you will design 
> the logging process for. Is it for finding issues with the 
> installation or is it for security breaches or auditing.
> These questions are good to put in mind when designing the logging process.
>
>
> Sent from my Samsung Galaxy smartphone. 
>  Original message
> From: Paul Angus 
> Date: 20/04/2016  1:01 PM  (GMT+04:00) To:
> d...@cloudstack.apache.org, users@cloudstack.apache.org
> Subject: RE: CloudStack Logging   Hi 
> Simon,
>
> My gut says that it's probably not worth going back before 4.3.  There 
> have been large changes since then but I think that it's better to get 
> as much data as possible, limiting to 4.6+ might not give a 
> particularly large install base.
>
>
> 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: Simon Weller [mailto:swel...@ena.com]
> Sent: 19 April 2016 21:51
> To: users@cloudstack.apache.org; d...@cloudstack.apache.org
> Subject: Re: CloudStack 

Re: CloudStack Logging

[Frank Louwers]

Hi Paul,

I’d love to see improvement in that area! Especially for my operational admins, 
the biggest issue we face is this:

- Someone wants to deploy a new VM, and it fails.

- Currently, it’s very hard to figure out exactly why. The best they get is 
“Capacity Planner failure”.

- They come to me :)


I think these failures are quite an easy use-case to improve logging on. If a 
VM can’t be started because of a “capacity” issue, it would we good to log (in 
a non-debug, non-info log):

- Which hosts were considered for CPU/Mem (based on zone, tags etc) (list them 
by name pref, not by “host 24” which means nothing to them as that number isn’t 
anywhere in the CS UI)

- Which of those considered hosts have the capacity needed (and for those that 
are excluded, weather they are excluded for RAM or CPU reasons)

- Exact same for Storage Pools

This would solve over 95% of my “Frank, I can’t find out why this VM won’t 
deploy” logging issues.

Regards,

Frank


> On 20 Apr 2016, at 22:05, Paul Angus  wrote:
> 
> Hi,
> 
> I don't think that it's a question of importance. INFO vs DEBUG should be 
> telling you different things. ERROR and WARN are also quite different.
> In general I'm targeting the cloud operational admins, the people who need to 
> know the health of their cloud and deal with issues as they're constantly 
> reading the log.
> 
> However, I'm not proposing to add or remove any messages, just revisit the 
> categorisation. If the 'operator' has their logging on debug they'd actually 
> see the same messages. The idea is to make turning the logging down to INFO 
> feasible.
> 
> You'd turn the logging back up to pick up code issues rather than just 
> operational issues.
> 
> Some VERY simplified definitions might be:
> 
> DEBUG:  inner workings of CloudStack that only a developer can 'understand'
> INFO:  actions that CloudStack is performing or information analysis (host 5 
> is full so not going to use it).
> WARN: this isn't good
> ERROR: something just didn't work.
> 
> 
> Grabbing a couple of examples
> 
> these should be debug - I can't 'do' anything with this information.
> 
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) Begin cleanup expired async-jobs
> INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-4119d5bc) End cleanup expired async-jobs
> INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-2:ctx-3209f65c) Scan 
> hung worker VM to recycle
> INFO  [c.c.h.v.r.VmwareResource] (DirectAgentCronJob-113:ctx-56d9f9f2) Scan 
> hung worker VM to recycle
> 
> Whereas this should be WARN. I wouldn't want to lose this by switching off 
> DEBUG
> 
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-91226be7) Detected 
> management node left, id:2, nodeIP:10.2.0.6
> DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-0bccd078) Detected 
> management node left, id:2, nodeIP:10.2.0.6
> 
> 
> 
> 
> 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: Chaz PC [mailto:dreeems4e...@hotmail.com] 
> Sent: 20 April 2016 11:32
> To: users@cloudstack.apache.org
> Subject: RE: CloudStack Logging
> 
> Hello,
> I have a question what is the criteria that you are going to follow to decide 
> the log record importance. Who is the user that you will design the logging 
> process for. Is it for finding issues with the installation or is it for 
> security breaches or auditing.
> These questions are good to put in mind when designing the logging process.
> 
> 
> Sent from my Samsung Galaxy smartphone. 
>  Original message 
> From: Paul Angus  
> Date: 20/04/2016  1:01 PM  (GMT+04:00) To: 
> d...@cloudstack.apache.org, users@cloudstack.apache.org Subject: 
> RE: CloudStack Logging   Hi Simon,
> 
> My gut says that it's probably not worth going back before 4.3.  There have 
> been large changes since then but I think that it's better to get as much 
> data as possible, limiting to 4.6+ might not give a particularly large 
> install base.
> 
> 
> 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: Simon Weller [mailto:swel...@ena.com]
> Sent: 19 April 2016 21:51
> To: users@cloudstack.apache.org; d...@cloudstack.apache.org
> Subject: Re: CloudStack Logging
> 
> 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.