[jira] [Commented] (CLOUDSTACK-9251) error while change instance offering to custom offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15115874#comment-15115874
]
Tomasz Zieba commented on CLOUDSTACK-9251:
--
Ok, I have understood the workaround but we have implemented few features which
use the custom offering.
Custom offering works without any problems in ACS4.5.2 and that's why upgrade
to ACS 4.7.1 is for us impossible.
I think that I have found the source of the problem.
When you are creating Instance and choose custom offering, you can start
instance with custom offering without any problems.
The function validateCustomParameters gets the following data ( named as
customParameters):
{cpuNumber=2, cpuSpeed=1500, memory=2048}
BUT
when you are changing offering on stopped instance the same function get the
following data ( named as customParameters):
{0={cpuNumber=2, cpuSpeed=2000, memory=2048}}
That's why validation is wrong. The functions inside method
validateCustomParameters can't get cpu count properly and method throws
Exception.
I'm sorry but I'm not java developer but maybe you can check the reason of this
situation.
Source file: server/src/com/cloud/vm/UserVmManagerImpl.java
> error while change instance offering to custom offering
> ---
>
> Key: CLOUDSTACK-9251
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9251
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.7.0, 4.7.1
> Environment: ACS 4.7.1 -
> https://dist.apache.org/repos/dist/dev/cloudstack/4.7.1/
>Reporter: Tomasz Zieba
>
> Changing compute offering to custom offering end with:
> Step to reproduce:
> 1. Create and run new instance with offering eg. 1 core / 1GB
> 2. Create Custom Offering eg 2 core / 2 GB
> 3. Stop the instance
> 4. Try to change offering of the instance
> 5. Error: Invalid cpu cores value, specify a value between 1 and 2147483647
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9251) error while change instance offering to custom offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112578#comment-15112578 ] Tomasz Zieba commented on CLOUDSTACK-9251: -- Hi, sorry i have forgotten. ACS 4.7.1 on CentOS 6.6 + 1 x XenServer 6.5 . This is test environment. > error while change instance offering to custom offering > --- > > Key: CLOUDSTACK-9251 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9251 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.7.0, 4.7.1 > Environment: ACS 4.7.1 - > https://dist.apache.org/repos/dist/dev/cloudstack/4.7.1/ >Reporter: Tomasz Zieba > > Changing compute offering to custom offering end with: > Step to reproduce: > 1. Create and run new instance with offering eg. 1 core / 1GB > 2. Create Custom Offering eg 2 core / 2 GB > 3. Stop the instance > 4. Try to change offering of the instance > 5. Error: Invalid cpu cores value, specify a value between 1 and 2147483647 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9251) error while change instance offering to custom offering
Tomasz Zieba created CLOUDSTACK-9251: Summary: error while change instance offering to custom offering Key: CLOUDSTACK-9251 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9251 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.7.0, 4.7.1 Environment: ACS 4.7.1 - https://dist.apache.org/repos/dist/dev/cloudstack/4.7.1/ Reporter: Tomasz Zieba Changing compute offering to custom offering end with: Step to reproduce: 1. Create and run new instance with offering eg. 1 core / 1GB 2. Create Custom Offering eg 2 core / 2 GB 3. Stop the instance 4. Try to change offering of the instance 5. Error: Invalid cpu cores value, specify a value between 1 and 2147483647 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8846) Performance issue in GUI - API command listVirtualMachines
Tomasz Zieba created CLOUDSTACK-8846: Summary: Performance issue in GUI - API command listVirtualMachines Key: CLOUDSTACK-8846 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8846 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.5.2 Environment: ACS 4.5.2 after upgrade from ACS 4.2.1 Reporter: Tomasz Zieba After upgrade to 4.5.2 from 4.2.1 we see strange performance issue. This performance issue occure only when we want to configure VPC network. Step to reproduce: Menu Network -> Select view to VPC -> click Configure on any network and we have to wait always about 20 - 40 seconds to complete The GUI call the following API command: api?command=listVirtualMachines&listAll=true&response=json&networkid=3e861c31-3f8c-46d2-a515-871d98a51d08&_=1442246472629 Could someone confirm this situation ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8347) Failed to create firewall rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba closed CLOUDSTACK-8347. Resolution: Not a Problem > Failed to create firewall rule > --- > > Key: CLOUDSTACK-8347 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8347 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.1 > Environment: ACS 4.5.1 from > http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release #224 >Reporter: Tomasz Zieba >Priority: Blocker > > Zone with Advanced networking. > Using GUI. > Network -> Guest networks > [some network] -> View IP Addresses -> [some > address] -> Configuration -> Firewall -> and add rule. > Network -> Guest networks > [some network] -> Egress rules -> add rule > Failed to create firewall rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8347) Failed to create firewall rule
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381920#comment-14381920
]
Tomasz Zieba commented on CLOUDSTACK-8347:
--
unfortunately yes:
Details below:
(local) 🐵 > create firewallrule cidrlist=0.0.0.0/0 protocol=tcp startport=23
endport=23 ipaddressid=a6c0f2e9-df44-4d5b-9f4b-d3f0c9e79489
Async job 46151edd-4a4c-4550-a11a-945599e856c5 failed
Error 530, Failed to create firewall rule
{
"accountid": "5d6b1a6c-a237-11e4-8dc9-e2241135c00c",
"cmd":
"org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd",
"created": "2015-03-26T15:11:25+0100",
"jobid": "46151edd-4a4c-4550-a11a-945599e856c5",
"jobinstanceid": "6ea50a7b-a129-4d03-b9b7-43eed87c7ab9",
"jobinstancetype": "FirewallRule",
"jobprocstatus": 0,
"jobresult": {
"errorcode": 530,
"errortext": "Failed to create firewall rule"
},
"jobresultcode": 530,
"jobresulttype": "object",
"jobstatus": 2,
"userid": "5d6b32f4-a237-11e4-8dc9-e2241135c00c"
}
additionally in GUI we can see rules with status deleting:
0.0.0.0/0 TCP 23 23 Deleting
> Failed to create firewall rule
> ---
>
> Key: CLOUDSTACK-8347
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8347
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1
> Environment: ACS 4.5.1 from
> http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release #224
>Reporter: Tomasz Zieba
>Priority: Blocker
>
> Zone with Advanced networking.
> Using GUI.
> Network -> Guest networks > [some network] -> View IP Addresses -> [some
> address] -> Configuration -> Firewall -> and add rule.
> Network -> Guest networks > [some network] -> Egress rules -> add rule
> Failed to create firewall rule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8347) Failed to create firewall rule
Tomasz Zieba created CLOUDSTACK-8347: Summary: Failed to create firewall rule Key: CLOUDSTACK-8347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8347 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.1 Environment: ACS 4.5.1 from http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release #224 Reporter: Tomasz Zieba Priority: Blocker Zone with Advanced networking. Using GUI. Network -> Guest networks > [some network] -> View IP Addresses -> [some address] -> Configuration -> Firewall -> and add rule. Network -> Guest networks > [some network] -> Egress rules -> add rule Failed to create firewall rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8175) wrong Debian template description for XenServer 6.5.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba resolved CLOUDSTACK-8175. -- Resolution: Fixed Fix Version/s: 4.5.0 The same as: https://issues.apache.org/jira/browse/CLOUDSTACK-8178 > wrong Debian template description for XenServer 6.5.0 > - > > Key: CLOUDSTACK-8175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: ACS 4.5.0 from > http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release > #159 >Reporter: Tomasz Zieba >Priority: Critical > Fix For: 4.5.0 > > Attachments: guest_os_hypervisor_table.png > > > Due to an error in the name of the template can not be created on the server > machine system XenServer 6.5.0. > Details in attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8176) problem with GUI in 4.5.0. "XenServer Traffic label" are not used when creating zone
Tomasz Zieba created CLOUDSTACK-8176: Summary: problem with GUI in 4.5.0. "XenServer Traffic label" are not used when creating zone Key: CLOUDSTACK-8176 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8176 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: ACS 4.5.0 from http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release #159 Reporter: Tomasz Zieba Priority: Critical problem with GUI in 4.5.0 Wizard (New zone): Create Zone -> Advanced networking -> Setup Network "XenServer Traffic label" are not used when creating zone. Wizard use the default settings "Use default gateway". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8175) wrong Debian template description for XenServer 6.5.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba updated CLOUDSTACK-8175: - Attachment: guest_os_hypervisor_table.png > wrong Debian template description for XenServer 6.5.0 > - > > Key: CLOUDSTACK-8175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: ACS 4.5.0 from > http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release > #159 >Reporter: Tomasz Zieba >Priority: Critical > Attachments: guest_os_hypervisor_table.png > > > Due to an error in the name of the template can not be created on the server > machine system XenServer 6.5.0. > Details in attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8175) wrong Debian template description for XenServer 6.5.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14287607#comment-14287607 ] Tomasz Zieba commented on CLOUDSTACK-8175: -- It should be: Debian Wheezy 7.0 (32-bit) and Debian Wheezy 7.0 (64-bit) > wrong Debian template description for XenServer 6.5.0 > - > > Key: CLOUDSTACK-8175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: ACS 4.5.0 from > http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release > #159 >Reporter: Tomasz Zieba >Priority: Critical > Attachments: guest_os_hypervisor_table.png > > > Due to an error in the name of the template can not be created on the server > machine system XenServer 6.5.0. > Details in attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8175) wrong Debian template description for XenServer 6.5.0
Tomasz Zieba created CLOUDSTACK-8175: Summary: wrong Debian template description for XenServer 6.5.0 Key: CLOUDSTACK-8175 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8175 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: ACS 4.5.0 from http://jenkins.buildacloud.org/view/4.5/job/package-rhel63-4.5/ release #159 Reporter: Tomasz Zieba Priority: Critical Due to an error in the name of the template can not be created on the server machine system XenServer 6.5.0. Details in attachment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7888) unable to create remote vpn because of special character in password
Tomasz Zieba created CLOUDSTACK-7888: Summary: unable to create remote vpn because of special character in password Key: CLOUDSTACK-7888 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7888 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.1, 4.4.1 Environment: ACS 4.2.1 , ACS 4.4.1 Reporter: Tomasz Zieba enter the password with a special character (#) statement causes the inability to remote vpn tunnel. Please correct the code to enter password in quotes. For example: Current situation: root@r-2284-VM:/etc/ppp# cat chap-secrets sin33 * CloudS980@#+=.-_ * ==> /var/log/daemon.log <== Nov 12 16:28:19 r-2284-VM xl2tpd[9460]: control_finish: Connection closed to x.x.x.x, serial 0 () Nov 12 16:28:19 r-2284-VM xl2tpd[9460]: Terminating pppd: sending TERM signal to pid 9855 Expected situation: root@r-2284-VM:/etc/ppp# cat chap-secrets sin33 * "CloudS980@#+=.-_" * Nov 12 16:28:59 r-2284-VM xl2tpd[9460]: Call established with x.x.x.x, Local: 50127, Remote: 1, Serial: 0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7827) storage migration timeout, loss of data
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206542#comment-14206542 ] Tomasz Zieba commented on CLOUDSTACK-7827: -- The same situation on ACS 4.2.1 > storage migration timeout, loss of data > --- > > Key: CLOUDSTACK-7827 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7827 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1 > Environment: CentOS 6.5, Xenserver 6.2 with latest patches, > Cloudstack 4.4.1 >Reporter: Vincent Vuong >Priority: Critical > > If a volume migration is not completed before the Cloudstack timeout is > reached, the VM cannot be started after being stopped. We have observed this > behavior with Cloudstack 4.1 – 4.4. Loss of data will occur if the admin > stops the VM before finding the new VHD chain. Here are the steps to > reproduce: > 1)Execute a storage migration on a running VM that will exceed the > Cloudstack timeout value. > 2)Storage migration will fail with Cloudstack reporting a “Host timed > out” but Xenserver continues with the volume migration. > 3)After Xenserver completes the volume migration, Xenserver deletes the > original VHD chain. The database volume “PATH” in Cloudstack is not updated > with the new VHD chain. > 4)VM cannot be started after being stopped. There is no way to find out > what the new VHD chain is if the VM has stopped. > Fix: > 1)While the VM is still running, run the following command to find the > new VHD file name: xe vbd-list vm-uuid= > 2)Stop the VM and copy the VHD chain back to the original primary storage > and update the volume “PATH” with the new VHD chain in the Cloudstack > database. > 3)Start the VM. > 2014-11-01 21:16:56,887 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] > (Work-Job-Executor-3:ctx-80290066 job-174/job-175 ctx-c104adfc) copy failed > com.cloud.utils.exception.CloudRuntimeException: Failed to send command, due > to Agent:4, com.cloud.exception.OperationTimedoutException: Commands > 1959910262836298211 to Host 4 timed out after 3600 > at > org.apache.cloudstack.storage.RemoteHostEndPoint.sendMessage(RemoteHostEndPoint.java:133) > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.migrateVolumeToPool(AncientDataMotionStrategy.java:383) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194367#comment-14194367
]
Tomasz Zieba commented on CLOUDSTACK-6036:
--
Thank you for the information.
Immediately'll check and if necessary re-open the issue.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> ACS 4.2.1 clean install
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Labels: 4.5ReviewNeeded
> Fix For: 4.4.0, 4.5.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7128) Secondary Storage size - display limits
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba resolved CLOUDSTACK-7128. -- Resolution: Fixed After the upgrade from version 3.0.2 to version 4.2.1 it turned out that the column "name" in the table "storage" contains the UUID instead of an entry identical to the URL column. Manual change solved the problem. > Secondary Storage size - display limits > --- > > Key: CLOUDSTACK-7128 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7128 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 >Reporter: Tomasz Zieba > > Are there known limits on Secondary Storage? > After joining 40TB Secondary Storage, dashboard shows 0.00KB/0.00KB in System > Capacity widget. > Also, the API returns the same values (0.00KB/0.00KB) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7128) Secondary Storage size - display limits
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184036#comment-14184036 ] Tomasz Zieba commented on CLOUDSTACK-7128: -- After the upgrade from version 3.0.2 to version 4.2.1 it turned out that the column "name" in the table "storage" contains the UUID instead of an entry identical to the URL column. Manual change solved the problem. > Secondary Storage size - display limits > --- > > Key: CLOUDSTACK-7128 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7128 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 >Reporter: Tomasz Zieba > > Are there known limits on Secondary Storage? > After joining 40TB Secondary Storage, dashboard shows 0.00KB/0.00KB in System > Capacity widget. > Also, the API returns the same values (0.00KB/0.00KB) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073335#comment-14073335
]
Tomasz Zieba commented on CLOUDSTACK-6036:
--
Hello,
After a little investigation, we have some facts. Error stopping the machine is
always associated with an entry in the logs of the content:
2014-07-24 17:00:34,918 DEBUG [vm.dao.VMInstanceDaoImpl] (HA-Worker-2:work-15)
Unable to update VM[User|Win-HD-tune]: DB Data={Host=null; State=Stopped;
updated=55; time=Thu Jul 24 17:00:34 CEST 2014} New Data: {Host=2;
State=Running; updated=55; time=Thu Jul 24 17:00:34 CEST 2014} Stale Data:
{Host=2; State=Stopping; updated=54; time=Thu Jul 24 17:00:13 CEST 2014}
and then:
2014-07-24 17:00:34,919 DEBUG [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-2:work-15) Stop was unsuccessful. Rescheduling
2014-07-24 17:00:34,919 INFO [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-2:work-15) Rescheduling HAWork[15-Stop-10-Stopping-Scheduled] to try
again at Thu Jul 24 17:10:48 CEST 2014
After analyzing the logs of the database:
633 Query UPDATE vm_instance SET vm_instance.update_time='2014-07-24
15:00:34', vm_instance.update_count=vm_instance.update_count+1,
vm_instance.last_host_id=2, vm_instance.state='Stopped',
vm_instance.host_id=null, vm_instance.pod_id=1 WHERE vm_instance.id = 10 AND
vm_instance.state = 'Stopping' AND vm_instance.host_id = 2 AND
vm_instance.update_count = 54
633 Query UPDATE vm_instance SET vm_instance.update_time='2014-07-24
15:00:34', vm_instance.update_count=vm_instance.update_count+1,
vm_instance.state='Running', vm_instance.host_id=2, vm_instance.pod_id=1 WHERE
vm_instance.id = 10 AND vm_instance.state = 'Stopping' AND
vm_instance.host_id = 2 AND vm_instance.update_count = 54
As can be seen ACS tries to update the entry twice but twice looking
vm_instance.update_count field with a value of 54
So the first update causes the counter vm_instance.update_count increased to 55
so once the second SQL Update command executed incorrectly.
My guess is that the situation is related to a race condition in the HA-Worker
threads, which by default is 5
In the test environment, we try to change ha.workers value to 1 and we will see
if the situation repeats itself.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> ACS 4.2.1 clean install
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Labels: 4.5ReviewNeeded
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , Mgmt
[jira] [Created] (CLOUDSTACK-7128) Secondary Storage size - display limits
Tomasz Zieba created CLOUDSTACK-7128: Summary: Secondary Storage size - display limits Key: CLOUDSTACK-7128 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7128 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.1 Environment: ACS 4.2.1 Reporter: Tomasz Zieba Are there known limits on Secondary Storage? After joining 40TB Secondary Storage, dashboard shows 0.00KB/0.00KB in System Capacity widget. Also, the API returns the same values (0.00KB/0.00KB) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6836) problem with VPN Site2Site - multinets
Tomasz Zieba created CLOUDSTACK-6836:
Summary: problem with VPN Site2Site - multinets
Key: CLOUDSTACK-6836
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6836
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: SystemVM
Affects Versions: 4.2.1, 4.3.0
Environment: ACS 4.2.1, ACS4.3
Reporter: Tomasz Zieba
There is a typo in /opt/cloud/bin/ipsectunnel.sh script on virtual router.
When using multiple nets (CIDR list) in VPN connection, ipsectunnel.sh script
create line as follows:
rightsubnets={192.168.6.0/24 10.13.1.0/24}
but this line should be:
rightsubnets={192.168.6.0/24,10.13.1.0/24}
Please change /opt/cloud/bin/ipsectunnel.sh, for example as follows:
add:
rightnets=${rightnets// /,}
befor lines:
sudo echo "conn vpn-$rightpeer" > $vpnconffile &&
sudo echo " left=$leftpeer" >> $vpnconffile &&
sudo echo " leftsubnet=$leftnet" >> $vpnconffile &&
sudo echo " leftnexthop=$leftgw" >> $vpnconffile &&
sudo echo " right=$rightpeer" >> $vpnconffile &&
sudo echo " rightsubnets={$rightnets}" >> $vpnconffile &&
sudo echo " type=tunnel" >> $vpnconffile &&
sudo echo " authby=secret" >> $vpnconffile &&
sudo echo " keyexchange=ike" >> $vpnconffile &&
sudo echo " ike=$ikepolicy" >> $vpnconffile &&
sudo echo " ikelifetime=${ikelifetime}s" >> $vpnconffile &&
sudo echo " esp=$esppolicy" >> $vpnconffile &&
sudo echo " salifetime=${esplifetime}s" >> $vpnconffile &&
sudo echo " pfs=$pfs" >> $vpnconffile &&
sudo echo " keyingtries=2" >> $vpnconffile &&
sudo echo " auto=add" >> $vpnconffile &&
sudo echo "$leftpeer $rightpeer: PSK \"$secret\"" > $vpnsecretsfile &&
sudo chmod 0400 $vpnsecretsfile
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6283) User can ommit secstorage.allowed.internal.sites limit
Tomasz Zieba created CLOUDSTACK-6283: Summary: User can ommit secstorage.allowed.internal.sites limit Key: CLOUDSTACK-6283 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6283 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.2.1 Environment: ACS4.2.1 CitrixXen 6.2SP1 Reporter: Tomasz Zieba The user is able to bypass the limitations of IP addresses for downloading templates in Global Settings: secstorage.allowed.internal.sites by specifying the URL with additionally port in addition to http, https, ie: http://x.y.v.z:8080/file.vhd The problem is the rules that are applied on the Secondary Storage VM: iptables -S OUTPUT -P OUTPUT ACCEPT -A OUTPUT-d 172.16.1.0/24-o eth1-p tcp-m state - state NEW-m tcp-j ACCEPT -A OUTPUT-o eth1-p tcp-m state - state NEW-m tcp - dport 80-j REJECT - reject-with icmp-port-unreachable -A OUTPUT-o eth1-p tcp-m state - state NEW-m tcp - dport 443-j REJECT - reject-with icmp-port-unreachable Limitations concern only ports 80 and 443 Is it possible to enter filtering the entire traffic or prohibit using the port in the URL ? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6035) error when displaying firewall rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919332#comment-13919332 ] Tomasz Zieba commented on CLOUDSTACK-6035: -- Problem exists on Firefox. Chrome is not affected. > error when displaying firewall rules > > > Key: CLOUDSTACK-6035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 after upgrade from 3.0.2 >Reporter: Tomasz Zieba > Attachments: CS_firewall_4.2.JPG, cloudstack_ui_firewall_error.JPG > > > After upgrade from 3.0.2 to 4.2.1. > In version 4.2.1 there was an error when displaying firewall rules. > If the number of rules is too high UI displays an error (screenshot > attached). > In the illustrated case it is 26 rules. > There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6035) error when displaying firewall rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912995#comment-13912995 ] Tomasz Zieba commented on CLOUDSTACK-6035: -- The problem exisits on guest networks. Please test firewall rules on guest networks not on security groups. > error when displaying firewall rules > > > Key: CLOUDSTACK-6035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 after upgrade from 3.0.2 >Reporter: Tomasz Zieba >Assignee: Namita Chaudhari > Attachments: CS_firewall_4.2.JPG, cloudstack_ui_firewall_error.JPG > > > After upgrade from 3.0.2 to 4.2.1. > In version 4.2.1 there was an error when displaying firewall rules. > If the number of rules is too high UI displays an error (screenshot > attached). > In the illustrated case it is 26 rules. > There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba reopened CLOUDSTACK-6036:
--
Steps to reproduce on ASC 4.2.1 (clean install) and on ASC 4.2.1 (upgrade from
3.0.2)
1. Running instance of the machine
1a) create script which delay stopping by 10 minutes
2. Stop VM
You can see in management-server.log.2014-02-24 any details.
Very strange thing is that:
a) when machine stopping process is delay'ed - HA-Worker take very dangerous
process - Stop was unsuccessful. Rescheduling. This is connected with "Unable
to update VM" status in DB.
b) consequently machine is stopped after 10 minutes but HA-Worker has a
rescheduled process of stopping machine.
c) so when you are starting a machine next time - it starts very well - but for
few minutes machine is stopped by reschduled process.
Details in attachement.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba updated CLOUDSTACK-6036:
-
Environment:
ACS 4.2.1 after upgrade from 3.0.2
ACS 4.2.1 clean install
XCP 1.1
was:
ACS 4.2.1 after upgrade from 3.0.2
XCP 1.1
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> ACS 4.2.1 clean install
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba updated CLOUDSTACK-6036:
-
Attachment: management-server.log.2014-02-24.txt
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5890) Error while collecting disk stats from vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13897919#comment-13897919 ] Tomasz Zieba commented on CLOUDSTACK-5890: -- This problem also occurs when you upgrade from version 3.0.2 to version 4.2.1 > Error while collecting disk stats from vm > - > > Key: CLOUDSTACK-5890 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5890 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.2.1, 4.3.0 >Reporter: Daan Hoogland > > "Error while collecting disk stats from" is thrown a lot of times. > 2014-01-16 00:00:56,006 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-137:null) Error while collecting disk stats from : > You gave an invalid object reference. The object may have recently been > deleted. The class parameter gives the type of reference given, and the > handle parameter echoes the bad value given. > at com.xensource.xenapi.Types.checkResponse(Types.java:209) > at com.xensource.xenapi.Connection.dispatch(Connection.java:368) > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) > at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2791) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2691) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > xapi returns HANDLE_INVALID, after which the whole collection process for > stops for this host as it is caught outside the loop. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6078) migration of volume between priamry storages - snapshots are disapear and scheduler is turned off
Tomasz Zieba created CLOUDSTACK-6078: Summary: migration of volume between priamry storages - snapshots are disapear and scheduler is turned off Key: CLOUDSTACK-6078 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6078 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.2.1 Environment: XS6.2SP1, XCP1.1 ACS4.2.1 Reporter: Tomasz Zieba Migration of volume between Primary Storages causes: - snapshot scheduler is disabled on new volume, - snapshots of source volume are visible only in global snapshot view - snapshots of the volume are empty -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6035) error when displaying firewall rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba updated CLOUDSTACK-6035: - Attachment: cloudstack_ui_firewall_error.JPG > error when displaying firewall rules > > > Key: CLOUDSTACK-6035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 after upgrade from 3.0.2 >Reporter: Tomasz Zieba > Attachments: cloudstack_ui_firewall_error.JPG > > > After upgrade from 3.0.2 to 4.2.1. > In version 4.2.1 there was an error when displaying firewall rules. > If the number of rules is too high UI displays an error (screenshot > attached). > In the illustrated case it is 26 rules. > There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
Tomasz Zieba created CLOUDSTACK-6036:
Summary: CloudStack stops the machine for no reason
Key: CLOUDSTACK-6036
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.1
Environment: ACS 4.2.1 after upgrade from 3.0.2
XCP 1.1
Reporter: Tomasz Zieba
Priority: Critical
After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
associated with self-stopping machine after changing the offering.
Steps to reproduce:
1. Running instance of the machine
2. Stop with the operating system
3. Change offering of machine
4. Start the machine
5. Waiting for 10 minutes
6. CloudStack stops the machine for no reason
7. Restart the machine
In the logs you can find information:
2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
2014-02-05 06:27:00,974 DEBUG [agent.transport.Request] (DirectAgent-316:null)
Seq 50-1756626952: Processing: { Ans: , MgmtId: 160544475005497, via: 50, Ver:
v1, Flags: 10,
[{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
}
2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
Running
2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
Running
2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] (HA-Worker-1:work-1511)
Seq 51-1374970375: Sending { Cmd , MgmtId: 160544475005497, via: 51, Ver: v1,
Flags: 100111,
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
}
2014-02-05 06:36:01,240 DEBUG [agent.transport.Request] (HA-Worker-1:work-1511)
Seq 51-1374970375: Executing: { Cmd , MgmtId: 160544475005497, via: 51, Ver:
v1, Flags: 100111,
[{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
}
2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
You will notice that the stop of the machine corresponds to the component
HA-Worker.
Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6035) error when displaying firewall rules
Tomasz Zieba created CLOUDSTACK-6035: Summary: error when displaying firewall rules Key: CLOUDSTACK-6035 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Environment: ACS 4.2.1 after upgrade from 3.0.2 Reporter: Tomasz Zieba After upgrade from 3.0.2 to 4.2.1. In version 4.2.1 there was an error when displaying firewall rules. If the number of rules is too high UI displays an error (screenshot attached). In the illustrated case it is 26 rules. There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6034) Deleting events by user
Tomasz Zieba created CLOUDSTACK-6034: Summary: Deleting events by user Key: CLOUDSTACK-6034 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6034 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Environment: ACS 4.2.1 Reporter: Tomasz Zieba In version 4.2.1 it is possible to remove events through UI. Events can be removed either by an administrator and a normal user. I think that, the removal of user events should be implemented through the hidden flag and no real removal events. In case of problems removing events complicates the diagnosis. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5422) Changing XenServer Tools Version 6.1 + doesnt work
Tomasz Zieba created CLOUDSTACK-5422: Summary: Changing XenServer Tools Version 6.1 + doesnt work Key: CLOUDSTACK-5422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5422 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: CloudStack 4.2.1 Reporter: Tomasz Zieba Priority: Blocker The situation is very similar to CLOUDSTACK-3806 and refers to the option XenServer Tools Version 6.1 + in Instances menu. Checking / unchecking this option when Instance does not affect the operation of the system. The problem identical to CLOUDSTACK-3806. The database does not change the corresponding field. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5332) Network offering don't use new system offering for router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba updated CLOUDSTACK-5332: - Description: Reproduction steps: 1. Create new system offering for Virtual Router. 2. Create new Network Offering. From "System Offering for Router" dropdown list choose VirtualRouter offering you've created in first step. 3. Try to deploy VM choosing newly created network offering. Bug Created network still runs a Virtual Router based on default offering. In database we can see that network offering is related to default system offering for router. Expected result Created network should use new System Offering for Virtual Router. We think that this is a problem with GUI or sql insert query, because in sql table named Network_Offering in the column named Service_Offering_ID is null value (default for this column). was: Reproduction steps: 1. Create new system offering for Virtual Router. 2. Create new Network Offering. From "System Offering for Router" dropdown list choose VirtualRouter offering you've created in first step. 3. Try to deploy VM choosing newly created network offering. Bug Created network still runs a Virtual Router based on default offering. In database we can see that network offering is related to default system offering for router. Expected result Created network should use new System Offering for Virtual Router. We think that this is a problem with GUI. > Network offering don't use new system offering for router > - > > Key: CLOUDSTACK-5332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5332 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: CloudStack 4.2.0 > CitrixXen 6.2 >Reporter: Tomasz Zieba > > Reproduction steps: > 1. Create new system offering for Virtual Router. > 2. Create new Network Offering. From "System Offering for Router" dropdown > list choose VirtualRouter offering you've created in first step. > 3. Try to deploy VM choosing newly created network offering. > Bug > Created network still runs a Virtual Router based on default offering. > In database we can see that network offering is related to default system > offering for router. > Expected result > Created network should use new System Offering for Virtual Router. > We think that this is a problem with GUI or sql insert query, because in sql > table named Network_Offering in the column named Service_Offering_ID is null > value (default for this column). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5332) Network offering don't use new system offering for router
Tomasz Zieba created CLOUDSTACK-5332: Summary: Network offering don't use new system offering for router Key: CLOUDSTACK-5332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5332 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: CloudStack 4.2.0 CitrixXen 6.2 Reporter: Tomasz Zieba Reproduction steps: 1. Create new system offering for Virtual Router. 2. Create new Network Offering. From "System Offering for Router" dropdown list choose VirtualRouter offering you've created in first step. 3. Try to deploy VM choosing newly created network offering. Bug Created network still runs a Virtual Router based on default offering. In database we can see that network offering is related to default system offering for router. Expected result Created network should use new System Offering for Virtual Router. We think that this is a problem with GUI. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3806) OS Preference can not be set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba updated CLOUDSTACK-3806: - Affects Version/s: 4.2.0 > OS Preference can not be set > > > Key: CLOUDSTACK-3806 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3806 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 > Environment: Typical instalation of CloudStack 4.1 >Reporter: Tomasz Zieba >Assignee: Anshul Gangwar > > You can not change OS Preference on Infrastructure-> Hosts -> Host . > After edit host and select OS-Preference - for example Windows and click > Apply You can see change. > But after refresh site OS Preference is back to None. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-3806) OS Preference can not be set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba reopened CLOUDSTACK-3806: -- CloudStack 4.2 Now I can change OS preference from none to for example Windows but I can not change OS preference back to None :-( The situation is the same as previous. After click Apply you can see change but after refresh site OS Preference is back to for example Windows. > OS Preference can not be set > > > Key: CLOUDSTACK-3806 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3806 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 > Environment: Typical instalation of CloudStack 4.1 >Reporter: Tomasz Zieba >Assignee: Anshul Gangwar > > You can not change OS Preference on Infrastructure-> Hosts -> Host . > After edit host and select OS-Preference - for example Windows and click > Apply You can see change. > But after refresh site OS Preference is back to None. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4036) UI remains in procesing state and queryAsyncJobResult geting called repeatedly for scaleSystemVm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814954#comment-13814954 ] Tomasz Zieba commented on CLOUDSTACK-4036: -- The same situation but in another environment: - CitrixXen 6.2 - CloudStack 4.2 Process: live migration systemvm's (routers, secondary vm, console proxy) to another host. Live migration has been done properly but UI never shows that task is finished. Example logs: 2013-11-06 16:03:15,894 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750202498 2013-11-06 16:03:18,871 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750205498 2013-11-06 16:03:18,892 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-3:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:18,900 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750205498 2013-11-06 16:03:21,865 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750208498 2013-11-06 16:03:21,887 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-1:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:21,895 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750208498 2013-11-06 16:03:24,872 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750211498 2013-11-06 16:03:24,893 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-4:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:24,901 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750211498 2013-11-06 16:03:27,871 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750214498 2013-11-06 16:03:27,892 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-5:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:27,902 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750214498 2013-11-06 16:03:30,879 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750217498 2013-11-06 16:03:30,901 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-6:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:30,910 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750217498 > UI remains in procesing state and queryAsyncJobResult geting called > repeatedly for scaleSystemVm > > > Key: CLOUDSTACK-4036 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4036 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Priority: Critical > Fix For: 4.2.1 > > Attachments: Logs_DB.rar, screenshot-1.jpg > > > Steps to reproduce > == > 1-preapre a CS setup with esxi5.1 > 2-create a SO for ssvm > 3-try scale up ssvm > Expected > -- > UI should not b
[jira] [Created] (CLOUDSTACK-4926) DHCP leases problem after network clean up
Tomasz Zieba created CLOUDSTACK-4926: Summary: DHCP leases problem after network clean up Key: CLOUDSTACK-4926 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4926 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: pre-4.0.0 Environment: CS 3.0.2, XCP 1.1 Reporter: Tomasz Zieba This would result in the user VM cannot get the IP address after reboot. After network restart with clean-up option all of the DHCP entries in router's /etc/dhcphosts.txt and /var/lib/misc/dnsmasq.leases are cleaned up. Without them it is not possible to get an IP address by the VM. Any attempt to get one fails with an entry in router's /var/log/dnsmasq.log: Oct 18 10:29:33 dnsmasq-dhcp[29525]: DHCPDISCOVER(eth0) 02:00:47:5a:00:42 no address available The only solution is to stop and then start VM again from Cloudstack UI only. When VM starts its new DHCP configuration is being sent to the router. DHCP configuration is not updated even if I restart the network without clean-up option selected. We expected that the whole DHCP configuration is generated and sent on network restart (with or without clean-up option), but it's not. Is this a normal behavior? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-904) CloudStack export the CPU as a socket not core
[
https://issues.apache.org/jira/browse/CLOUDSTACK-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738430#comment-13738430
]
Tomasz Zieba commented on CLOUDSTACK-904:
-
The same situation with CitrixXen / XCP but we made a patch:
Environment
- CloudStack 3.0.2
- XCP 1.1
in file: core/src/com/cloud/hypervisor/xen/resource/CitrixRecourceBase.java
public int getOptimalNumberOfCores(int vmCPUsCount) {
if (vmCPUsCount % 4 == 0) {return 4;}
else if (vmCPUsCount % 2 == 0) {return 2;}
else return 1;
}
protected VM createVmFromTemplate(Connection conn, VirtualMachineTO vmSpec,
Host host) throws XenAPIException, XmlRpcException {
String guestOsTypeName = getGuestOsType(vmSpec.getOs(),
vmSpec.getBootloader() == BootloaderType.CD);
if ( guestOsTypeName == null ) {
..
if (vcpuParams.size() > 0) {
vm.setVCPUsParams(conn, vcpuParams);
}
// change cores per socket according to:
http://support.citrix.com/article/CTX126524
if ((long)vmSpec.getCpus() > 1) {
int optimalCoresCount =
getOptimalNumberOfCores(vmSpec.getCpus());
vm.addToPlatform(conn, "cores-per-socket",
Integer.toString(optimalCoresCount));
}
vm.setActionsAfterCrash(conn, Types.OnCrashBehaviour.DESTROY);
vm.setActionsAfterShutdown(conn, Types.OnNormalExit.DESTROY);
..
There is an issue/problem because Microsoft Windows Server Standard is licensed
to maximum 4 cpus sockets.
> CloudStack export the CPU as a socket not core
> --
>
> Key: CLOUDSTACK-904
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-904
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: pre-4.0.0, 4.0.0
>Reporter: Ahmad Saif
>
> I've a VM that's running (Windows 2008 Standard R2 64bit) which was working
> on a 4 cores offer. when I upgraded the service offer to 8 cores and checked
> the VM I noticed that it still have only 4 cores !!
> I dig a little bit on the windows machine itself, and found that it see the
> CPUs as sockets not cores and this version of windows support only up to 4
> cores.
> when I checked the vm XML file on the host I saw that the CPU is exported as
> following :
> 8
> and it should be exported as following:
> 1
>
>
> otherwise in such systems where you are limited with the sockets number you
> cannot have the required service offer.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-3806) OS Preference can not be set
Tomasz Zieba created CLOUDSTACK-3806: Summary: OS Preference can not be set Key: CLOUDSTACK-3806 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3806 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: Typical instalation of CloudStack 4.1 Reporter: Tomasz Zieba You can not change OS Preference on Infrastructure-> Hosts -> Host . After edit host and select OS-Preference - for example Windows and click Apply You can see change. But after refresh site OS Preference is back to None. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2675) Missing network_id on restarting/host adding to a new shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Zieba closed CLOUDSTACK-2675. Resolution: Fixed Fix Version/s: 4.1.0 This issue has been solved in version 4.1.0. > Missing network_id on restarting/host adding to a new shared network > > > Key: CLOUDSTACK-2675 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2675 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.2 > Environment: CloudStack 4.0.2, >Reporter: Tomasz Zieba > Fix For: 4.1.0 > > > I have got the same situation as follows: > http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3c4b77b928-a3c5-4742-8ac3-652af4a7c...@ringplus.net%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2675) Missing network_id on restarting/host adding to a new shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676929#comment-13676929 ] Tomasz Zieba commented on CLOUDSTACK-2675: -- This issue has been solved in version 4.1.0. > Missing network_id on restarting/host adding to a new shared network > > > Key: CLOUDSTACK-2675 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2675 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.2 > Environment: CloudStack 4.0.2, >Reporter: Tomasz Zieba > > I have got the same situation as follows: > http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3c4b77b928-a3c5-4742-8ac3-652af4a7c...@ringplus.net%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2675) Missing network_id on restarting/host adding to a new shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673304#comment-13673304 ] Tomasz Zieba commented on CLOUDSTACK-2675: -- I have found that there is a problem with INSERT SQL statement. When you are creating vm machine and take a shared network, CloudStack create following sql statements: 8 Query SET autocommit=0 8 Query SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 8 Query SELECT 1 8 Query SET autocommit=1 8 Query SELECT vm_template.id, vm_template.format, vm_template.unique_name, vm_template.name, vm_template.public, vm_template.featured, vm_template.type, vm_template.url, vm_template.hvm, vm_template.bits, vm_template.created, vm_template.removed, vm_template.account_id, vm_template.checksum, vm_template.display_text, vm_template.enable_password, vm_template.guest_os_id, vm_template.bootable, vm_template.prepopulate, vm_template.cross_zones, vm_template.hypervisor_type, vm_template.extractable, vm_template.source_template_id, vm_template.template_tag, vm_template.uuid, vm_template.sort_key, vm_template.enable_sshkey FROM vm_template WHERE vm_template.type = 'SYSTEM' AND vm_template.hypervisor_type = 'XenServer' ORDER BY vm_template.id DESC 8 Query SET autocommit=1 9 Query SET autocommit=0 9 Query SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 9 Query SELECT 1 9 Query SET autocommit=0 9 Query INSERT INTO vm_instance (vm_instance.id, vm_instance.name, vm_instance.vnc_password, vm_instance.proxy_id, vm_instance.proxy_assign_time, vm_instance.state, vm_instance.private_ip_address, vm_instance.instance_name, vm_instance.vm_template_id, vm_instance.guest_os_id, vm_instance.host_id, vm_instance.last_host_id, vm_instance.pod_id, vm_instance.private_mac_address, vm_instance.data_center_id, vm_instance.vm_type, vm_instance.ha_enabled, vm_instance.limit_cpu_use, vm_instance.update_count, vm_instance.created, vm_instance.update_time, vm_instance.domain_id, vm_instance.account_id, vm_instance.service_offering_id, vm_instance.reservation_id, vm_instance.hypervisor_type, vm_instance.uuid, vm_instance.type) VALUES (29, _binary'r-29-VM', _binary'L2fmUmx6ikdjMva5WFwRleblZTgaCjdH8JPYTcAVmcQ=', null, null, 'Stopped', null, _binary'r-29-VM', 1, 15, null, null, null, null, 1, 'DomainRouter', 1, 0, 0, '2013-06-03 14:27:17', null, 1, 1, 7, null, 'XenServer', _binary'29443e94-3960-4370-8970-4f2917bfb940', 'DomainRouter') 9 Query INSERT INTO domain_router (domain_router.element_id, domain_router.public_ip_address, domain_router.public_mac_address, domain_router.public_netmask, domain_router.is_redundant_router, domain_router.priority, domain_router.is_priority_bumpup, domain_router.redundant_state, domain_router.stop_pending, domain_router.role, domain_router.template_version, domain_router.scripts_version, domain_router.vpc_id, domain_router.id) VALUES (2, null, null, null, 0, 0, 0, 'UNKNOWN', 0, 'VIRTUAL_ROUTER', null, null, null, 29) 9 Query rollback 9 Query rollback 9 Query SET autocommit=1 There is a problem with " INSERT INTO domain_router " statement because the definition of domain_router table is the following: mysql> describe domain_router; +-+-+--+-+-+---+ | Field | Type| Null | Key | Default | Extra | +-+-+--+-+-+---+ | id | bigint(20) unsigned | NO | PRI | NULL| | | element_id | bigint(20) unsigned | NO | MUL | NULL| | | public_mac_address | varchar(17) | YES | | NULL| | | public_ip_address | char(40)| YES | | NULL| | | public_netmask | varchar(15) | YES | | NULL| | | guest_netmask | varchar(15) | YES | | NULL| | | guest_ip_address| char(40)| YES | | NULL| | | network_id | bigint(20) unsigned | NO | | NULL| | | is_redundant_router | int(1) unsigned | NO | | NULL| | | priority| int(4) unsigned | YES | | NULL| | | is_priority_bumpup | int(1) unsigned | NO | | NULL| | | redundant_state | varchar(64) | NO | | NULL| | | stop_pending| int(1) unsigned | NO | | NULL| | | role| varchar(64) | NO | | NULL| | | template_version| varchar(100)
[jira] [Created] (CLOUDSTACK-2675) Missing network_id on restarting/host adding to a new shared network
Tomasz Zieba created CLOUDSTACK-2675: Summary: Missing network_id on restarting/host adding to a new shared network Key: CLOUDSTACK-2675 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2675 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.2 Environment: CloudStack 4.0.2, Reporter: Tomasz Zieba I have got the same situation as follows: http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3c4b77b928-a3c5-4742-8ac3-652af4a7c...@ringplus.net%3E -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2612) some typo in schema-302to40.sql
Tomasz Zieba created CLOUDSTACK-2612:
Summary: some typo in schema-302to40.sql
Key: CLOUDSTACK-2612
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2612
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.0.2
Environment: upgrade from CS 3.0.2 to CS 4.0.2
Reporter: Tomasz Zieba
Please change the following lines to make upgrade successful:
/usr/share/cloud/setup/db/schema-302to40.sql
137c137
< DELETE FROM `cloud`.`storage_pool_host_ref` WHERE pool_id IN (SELECT id FROM
storage_pool WHERE removed IS NOT NULL);
---
> DELETE FROM `cloud`.`storage_pool_host_ref` WHERE pool_id IN (SELECT id FROM
> cloud.storage_pool WHERE removed IS NOT NULL);
182c182
< DELETE FROM `cloud`.`storage_pool_host_ref` WHERE pool_id IN (SELECT id FROM
storage_pool WHERE removed IS NOT NULL);
---
> DELETE FROM `cloud`.`storage_pool_host_ref` WHERE pool_id IN (SELECT id FROM
> cloud.storage_pool WHERE removed IS NOT NULL);
189c189
< ALTER TABLE `storage_pool` ADD `user_info` VARCHAR( 255 ) NULL COMMENT
'Authorization information for the storage pool. Used by network filesystems'
AFTER `host_address`;
---
> ALTER TABLE `cloud`.`storage_pool` ADD `user_info` VARCHAR( 255 ) NULL
> COMMENT 'Authorization information for the storage pool. Used by network
> filesystems' AFTER `host_address`;
235c235
< ALTER TABLE physical_network_service_providers DROP FOREIGN KEY
fk_pnetwork_service_providers__physical_network_id;
---
> ALTER TABLE `cloud`.`physical_network_service_providers` DROP FOREIGN KEY
> fk_pnetwork_service_providers__physical_network_id;
237c237
< SET @constraintname = (select CONCAT(CONCAT('DROP INDEX ',
A.CONSTRAINT_NAME), ' ON physical_network_service_providers' )
---
> SET @constraintname = (select CONCAT(CONCAT('DROP INDEX ',
> A.CONSTRAINT_NAME), ' ON cloud.physical_network_service_providers' )
246c246
< AlTER TABLE physical_network_service_providers ADD CONSTRAINT
`fk_pnetwork_service_providers__physical_network_id` FOREIGN KEY
(`physical_network_id`) REFERENCES `physical_network`(`id`) ON DELETE CASCADE;
---
> AlTER TABLE `cloud`.`physical_network_service_providers` ADD CONSTRAINT
> `fk_pnetwork_service_providers__physical_network_id` FOREIGN KEY
> (`physical_network_id`) REFERENCES `cloud`.`physical_network`(`id`) ON DELETE
> CASCADE;
481,482d480
<
<
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
