[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15596548#comment-15596548 ] ASF GitHub Bot commented on CLOUDSTACK-9504: Github user mike-tutkowski commented on the issue: https://github.com/apache/cloudstack/pull/1642 @rhtyd I changed the SHA and re-pushed the commit. Hopefully that will clear up Travis. > Fully support system VMs on managed storage > --- > > Key: CLOUDSTACK-9504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.10.0.0 > > > There are three related items for this ticket: > 1) Do not permit "custom IOPS" as a parameter when creating a system offering > (throw an exception if this parameter is passed in). > 2) If you transition managed storage into maintenance mode and system VMs > were running on that managed storage, the host-side clustered file systems > (SRs on XenServer) are not removed. Remove them. > 3) Add integration tests for system VMs with managed storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595967#comment-15595967 ] ASF GitHub Bot commented on CLOUDSTACK-9456: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1638 Trillian test result (tid-152) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 38948 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1638-t152-vmware-55u3.zip Test completed. 45 look ok, 3 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 1057.71 | test_privategw_acl.py test_01_vpc_privategw_acl | `Failure` | 183.01 | test_privategw_acl.py test_oobm_zchange_password | `Failure` | 20.53 | test_outofbandmanagement.py test_01_vpc_site2site_vpn | `Error` | 466.82 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 708.24 | test_vpc_vpn.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 835.74 | test_privategw_acl.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 896.51 | test_privategw_acl.py test_3d_gpu_support | `Error` | 386.27 | test_deploy_vgpu_enabled_vm.py test_01_vpc_remote_access_vpn | Success | 161.78 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 410.80 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 707.87 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 712.56 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1540.00 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 689.93 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 647.15 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1366.03 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 30.85 | test_volumes.py test_06_download_detached_volume | Success | 60.57 | test_volumes.py test_05_detach_volume | Success | 110.34 | test_volumes.py test_04_delete_attached_volume | Success | 20.27 | test_volumes.py test_03_download_attached_volume | Success | 15.30 | test_volumes.py test_02_attach_volume | Success | 58.97 | test_volumes.py test_01_create_volume | Success | 514.46 | test_volumes.py test_03_delete_vm_snapshots | Success | 280.27 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 232.23 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 136.55 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 161.65 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 248.56 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.86 | test_vm_life_cycle.py test_09_expunge_vm | Success | 185.32 | test_vm_life_cycle.py test_08_migrate_vm | Success | 116.47 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.11 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.15 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.15 | test_vm_life_cycle.py test_02_start_vm | Success | 20.24 | test_vm_life_cycle.py test_01_stop_vm | Success | 10.15 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 292.25 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 25.36 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.14 | test_templates.py test_01_create_template | Success | 176.27 | test_templates.py test_10_destroy_cpvm | Success | 242.06 | test_ssvm.py test_09_destroy_ssvm | Success | 244.08 | test_ssvm.py test_08_reboot_cpvm | Success | 157.00 | test_ssvm.py test_07_reboot_ssvm | Success | 158.70 | test_ssvm.py test_06_stop_cpvm | Success | 212.31 | test_ssvm.py test_05_stop_ssvm | Success | 269.33 | test_ssvm.py test_04_cpvm_internals | Success | 1.18 | test_ssvm.py test_03_ssvm_internals | Success | 3.95 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 21.23 | test_snapshots.py test_04_change_offering_small | Success | 132.26 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_of
[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595663#comment-15595663 ] ASF GitHub Bot commented on CLOUDSTACK-9456: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1638 Trillian test result (tid-150) Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6 Total time taken: 36494 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1638-t150-xenserver-65sp1.zip Test completed. 45 look ok, 3 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_05_rvpc_multi_tiers | `Failure` | 531.51 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 1398.21 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 641.24 | test_vpc_redundant.py test_04_rvpc_privategw_static_routes | `Failure` | 830.98 | test_privategw_acl.py test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 572.62 | test_privategw_acl.py test_02_vpc_privategw_static_routes | `Failure` | 682.24 | test_privategw_acl.py test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80 | `Error` | 924.47 | test_internal_lb.py test_01_vpc_site2site_vpn | Success | 307.10 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 141.91 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 559.26 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 387.04 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 669.35 | test_vpc_router_nics.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 960.25 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 1069.88 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 16.01 | test_volumes.py test_08_resize_volume | Success | 91.14 | test_volumes.py test_07_resize_fail | Success | 111.48 | test_volumes.py test_06_download_detached_volume | Success | 30.62 | test_volumes.py test_05_detach_volume | Success | 100.34 | test_volumes.py test_04_delete_attached_volume | Success | 10.26 | test_volumes.py test_03_download_attached_volume | Success | 15.40 | test_volumes.py test_02_attach_volume | Success | 10.84 | test_volumes.py test_01_create_volume | Success | 393.24 | test_volumes.py test_03_delete_vm_snapshots | Success | 280.25 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 201.79 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 105.91 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 294.41 | test_vm_life_cycle.py test_deploy_vm | Success | 0.04 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 27.43 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.26 | test_vm_life_cycle.py test_08_migrate_vm | Success | 71.48 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.15 | test_vm_life_cycle.py test_06_destroy_vm | Success | 5.17 | test_vm_life_cycle.py test_03_reboot_vm | Success | 10.21 | test_vm_life_cycle.py test_02_start_vm | Success | 20.30 | test_vm_life_cycle.py test_01_stop_vm | Success | 30.35 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 161.55 | test_templates.py test_08_list_system_templates | Success | 0.06 | test_templates.py test_07_list_public_templates | Success | 0.06 | test_templates.py test_05_template_permissions | Success | 0.66 | test_templates.py test_04_extract_template | Success | 5.37 | test_templates.py test_03_delete_template | Success | 5.15 | test_templates.py test_02_edit_template | Success | 90.19 | test_templates.py test_01_create_template | Success | 112.01 | test_templates.py test_10_destroy_cpvm | Success | 256.93 | test_ssvm.py test_09_destroy_ssvm | Success | 259.37 | test_ssvm.py test_08_reboot_cpvm | Success | 142.15 | test_ssvm.py test_07_reboot_ssvm | Success | 144.58 | test_ssvm.py test_06_stop_cpvm | Success | 192.25 | test_ssvm.py test_05_stop_ssvm | Success | 169.61 | test_ssvm.py test_04_cpvm_internals | Success | 1.25 | test_ssvm.py test_03_ssvm_internals | Success | 4.29 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.16 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.15 | test_ssvm.py test_01_snapshot_root_disk | Success | 26.93 | test_snapshots.py test_04_change_offering_small | Success | 126.38 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.10 | test_service_offerings.py test_01_create_service_o
[jira] [Commented] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595628#comment-15595628 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1697 @syed This is the PR we discussed on the call today. > Disable copy snapshot to secondary storage snapshot.backup.rightafter > - > > Key: CLOUDSTACK-4858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: kvm, rbd >Reporter: Sebastian Igerl > > "snapshot.backup.rightafterbackup" is set to false but still the snapshot is > copied to secondary storage. > Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the > management server and the nodes. > see : > http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595525#comment-15595525
]
ASF GitHub Bot commented on CLOUDSTACK-7982:
Github user mlsorensen commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1709#discussion_r84509497
--- Diff: core/src/com/cloud/agent/api/CancelMigrationCommand.java ---
@@ -0,0 +1,35 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+package com.cloud.agent.api;
+
+public class CancelMigrationCommand extends Command {
--- End diff --
Along these lines of cancellation, I've long thought that we really need
the ability to clean up long running jobs if the agent disconnects from the
management server for any reason (say upgrade or restart of agent or management
server, network problems, etc). Normally the management server will know the
job failed but the agent keeps on trucking, causing problems, especially for
things like migrations of storage. This may be an important thing to add for
this feature, to avoid situations where a migration completes but CloudStack
does not know about it because the management server was restarted during the
migration.
Rather than forcing the management server to know that the agent work needs
to be cleaned up and sending a command to the hypervisor that is tailored to
each command that can fail, one solution that I've seen implemented that has
worked well is for LibvirtComputingResource to hold a global List of
tasks, then it overrides the disconnected() method and loops through this list,
running the tasks. It then exposes methods addDisconnectHook(Runnable hook) and
removeDisconnectHook(Runnable hook) so that commands that are sensitive to
being interrupted can add in cancellation logic in the case of disconnect
before starting and remove it when finished.
Something like:
@Override
public void disconnected() {
this._connected = false;
s_logger.info("Detected agent disconnect event, running through " +
_disconnectHooks.size() + " disconnect hooks");
for (Runnable hook : _disconnectHooks) {
hook.run();
}
_disconnectHooks.clear();
}
public void addDisconnectHook(Runnable hook) {
s_logger.debug("Adding disconnect hook " + hook);
_disconnectHooks.add(hook);
}
public void removeDisconnectHook(Runnable hook) {
s_logger.debug("Removing disconnect hook " + hook);
if (_disconnectHooks.contains(hook)) {
s_logger.debug("Removing disconnect hook " + hook);
_disconnectHooks.remove(hook);
} else {
s_logger.debug("Requested removal of disconnect hook, but hook
not found: " + hook);
}
}
An example hook to cancel the migration might look like this:
public class MigrationCancelHook extends Thread {
private static final Logger LOGGER =
Logger.getLogger(MigrationCancelHook.class.getName());
private static final String HOOK_PREFIX = "MigrationCancelHook-";
Domain _migratingDomain;
String _vmName;
public MigrationCancelHook(Domain migratingDomain) throws
LibvirtException {
super(HOOK_PREFIX + migratingDomain.getName());
_migratingDomain = migratingDomain;
_vmName = migratingDomain.getName();
}
@Override
public void run() {
LOGGER.info("Interrupted migration of " + _vmName);
try {
if (_migratingDomain.abortJob() == 0) {
LOGGER.warn("Aborted migration job for " + _vmName);
}
} catch (Exception ex) {
LOGGER.warn("Failed to abort migration job for " + _vmName,
ex);
}
}
}
> Storage live migration support f
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595423#comment-15595423
]
ASF GitHub Bot commented on CLOUDSTACK-7982:
Github user wido commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1709#discussion_r84501931
--- Diff:
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
---
@@ -943,6 +962,11 @@ public boolean configure(final String name, final
Map params) th
_mountPoint = "/mnt";
}
+_libvirtConnectionProtocol = (String)
params.get("libvirt.connection.protocol");
+if (_libvirtConnectionProtocol == null) {
+_libvirtConnectionProtocol = "qemu://";
--- End diff --
Isn't this redundant since you already specify qemu:// at the beginning of
LibvirtComputingResource?
> Storage live migration support for KVM
> --
>
> Key: CLOUDSTACK-7982
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Marc-Aurèle Brothier
> Fix For: Future
>
>
> Currently it supports Xenserver, Vmware, Hyper-V, but not KVM.
> We need to add the implementation for KVM.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595409#comment-15595409 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1700 @NuxRo The first test would be to run this code and actually see that the API returns a IPv6 address which you can then use to reach your Instance. > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595333#comment-15595333 ] ASF GitHub Bot commented on CLOUDSTACK-9456: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1638 Trillian test result (tid-151) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29915 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1638-t151-kvm-centos7.zip Test completed. 47 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_02_vpc_privategw_static_routes | `Failure` | 239.63 | test_privategw_acl.py test_01_vpc_site2site_vpn | Success | 170.22 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 91.49 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 276.05 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 309.88 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 672.81 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 517.20 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1458.01 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 687.84 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 777.17 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1380.00 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.61 | test_volumes.py test_08_resize_volume | Success | 15.42 | test_volumes.py test_07_resize_fail | Success | 20.48 | test_volumes.py test_06_download_detached_volume | Success | 15.34 | test_volumes.py test_05_detach_volume | Success | 100.30 | test_volumes.py test_04_delete_attached_volume | Success | 10.21 | test_volumes.py test_03_download_attached_volume | Success | 15.29 | test_volumes.py test_02_attach_volume | Success | 74.84 | test_volumes.py test_01_create_volume | Success | 730.76 | test_volumes.py test_deploy_vm_multiple | Success | 263.89 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.86 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.27 | test_vm_life_cycle.py test_08_migrate_vm | Success | 41.01 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py test_06_destroy_vm | Success | 126.02 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.96 | test_vm_life_cycle.py test_02_start_vm | Success | 10.22 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.36 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 156.36 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.07 | test_templates.py test_04_extract_template | Success | 5.24 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.19 | test_templates.py test_01_create_template | Success | 65.78 | test_templates.py test_10_destroy_cpvm | Success | 191.81 | test_ssvm.py test_09_destroy_ssvm | Success | 163.89 | test_ssvm.py test_08_reboot_cpvm | Success | 161.69 | test_ssvm.py test_07_reboot_ssvm | Success | 133.82 | test_ssvm.py test_06_stop_cpvm | Success | 192.05 | test_ssvm.py test_05_stop_ssvm | Success | 138.97 | test_ssvm.py test_04_cpvm_internals | Success | 1.31 | test_ssvm.py test_03_ssvm_internals | Success | 4.50 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 16.33 | test_snapshots.py test_04_change_offering_small | Success | 240.61 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py test_01_create_service_offering | Success | 0.11 | test_service_offerings.py test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.22 | test_secondary_storage.py test_09_reboot_router | Success | 40.38 | test_routers.py test_08_start_router | Success | 30.30 | test_routers.py test_07_stop_router | Success | 10.17 | test_routers.py test_06_router_advanced | Success | 0.06 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py test
[jira] [Commented] (CLOUDSTACK-9507) Make listVM cmd response's guest os type field consistent with listTemplate reponse's
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15595202#comment-15595202 ] ASF GitHub Bot commented on CLOUDSTACK-9507: Github user serg38 commented on the issue: https://github.com/apache/cloudstack/pull/1686 @rhtyd This clearly a bug. os_type_id was always supposed to be a OS type as per: @SerializedName(ApiConstants.OS_TYPE_ID) @Param(description = "OS type id of the vm", since = "4.4") private String osTypeId; Currently it returns an OS Id. Guest OS UUID is already part of response as guestosid . Basically there are 3 options: 1. Fix current bug and correctly return OS type ID as os_type_id 2. Fix current bug but return OS type UUID as os_type_id 3. Fix current bug and correctly return OS type ID as os_type_id plus add a new response os_type_uuid that would be returning UUID of the guest Os category. I think #3 is overkill. I am for #2. > Make listVM cmd response's guest os type field consistent with listTemplate > reponse's > - > > Key: CLOUDSTACK-9507 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9507 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.10.0.0, 4.9.2.0, 4.9.1.0 > > > list virtualmachines response's ostypeid returned is an integer while, the > list templates API returns a uuid in the ostypeid key. The fix would be to > make the API consistent for users to only/always return uuids as id/integers > may not be consumable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9559) Deleting zone without deleting the secondary storage under the zone should not be allowed
subhash yedugundla created CLOUDSTACK-9559: -- Summary: Deleting zone without deleting the secondary storage under the zone should not be allowed Key: CLOUDSTACK-9559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9559 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Secondary Storage Affects Versions: 4.8.0 Environment: All Hypervisors Reporter: subhash yedugundla Fix For: 4.8.1 When a zone is deleted, with out deleting the corresponding secondary storage. If there are templates or volumes in secondary storage, it wont be possible to delete them from ACS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] subhash yedugundla updated CLOUDSTACK-9557: --- Description: Steps to reproduce the issue i) Upload a template as admin user and make sure "public" is selected when uploading it. ii) Now login as a user to CloudStack and deploy a VM with the template created in step i). iii) Create a VM snapshot as the user for the VM in step ii). Once created deploy a VM from the snapshot ( this will work as expected) iv) Now login as admin again , edit the template created in step i) and Uncheck "public". This is make the template as private ( or else delete the template from UI) v) Login as same user as in step ii) and try to create a VM from the same snapshot ( created in step iii)). This will fail now. was: Steps to reproduce the issue i) Upload a template as admin user and make sure "public" is selected when uploading it. ii) Now login as a user to CloudPlatform and deploy a VM with the template created in step i). iii) Create a VM snapshot as the user for the VM in step ii). Once created deploy a VM from the snapshot ( this will work as expected) iv) Now login as admin again , edit the template created in step i) and Uncheck "public". This is make the template as private ( or else delete the template from UI) v) Login as same user as in step ii) and try to create a VM from the same snapshot ( created in step iii)). This will fail now. > Deploy from VMsnapshot fails with exception if source template is removed or > made private > - > > Key: CLOUDSTACK-9557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.8.0 > Environment: Any Hypervisor >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > i) Upload a template as admin user and make sure "public" is selected when > uploading it. > ii) Now login as a user to CloudStack and deploy a VM with the template > created in step i). > iii) Create a VM snapshot as the user for the VM in step ii). Once created > deploy a VM from the snapshot ( this will work as expected) > iv) Now login as admin again , edit the template created in step i) and > Uncheck "public". This is make the template as private ( or else delete the > template from UI) > v) Login as same user as in step ii) and try to create a VM from the same > snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9558) Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594838#comment-15594838 ] ASF GitHub Bot commented on CLOUDSTACK-9558: GitHub user yvsubhash opened a pull request: https://github.com/apache/cloudstack/pull/1722 CLOUDSTACK-9558 Cleanup the snapshots on the primary storage of Xense… Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged You can merge this pull request into a Git repository by running: $ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9558 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1722.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1722 commit 0ff5a5329ec047fe4872347a26236da75ce5eef7 Author: subhash_y Date: 2016-08-29T05:15:03Z CLOUDSTACK-9558 Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged > Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is > expunged > - > > Key: CLOUDSTACK-9558 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9558 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.8.0 > Environment: Xen Server >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > === > i) Deploy a new VM in CCP on Xenserver > ii) Create a snapshot for the volume created in step i) from CCP. This step > will create a snapshot on the primary storage and keeps it on storage as we > use it as reference for the incremental snapshots > iii) Now destroy and expunge the VM created in step i) > You will notice that the volume for the VM ( created in step i) is deleted > from the primary storage. However the snapshot created on primary ( as part > of step ii)) still exists on the primary and this needs to be deleted > manually by the admin. > Snapshot exists on the primary storage even after deleting the Volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9558) Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged
subhash yedugundla created CLOUDSTACK-9558: -- Summary: Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged Key: CLOUDSTACK-9558 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9558 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.8.0 Environment: Xen Server Reporter: subhash yedugundla Fix For: 4.8.1 Steps to reproduce the issue === i) Deploy a new VM in CCP on Xenserver ii) Create a snapshot for the volume created in step i) from CCP. This step will create a snapshot on the primary storage and keeps it on storage as we use it as reference for the incremental snapshots iii) Now destroy and expunge the VM created in step i) You will notice that the volume for the VM ( created in step i) is deleted from the primary storage. However the snapshot created on primary ( as part of step ii)) still exists on the primary and this needs to be deleted manually by the admin. Snapshot exists on the primary storage even after deleting the Volume. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594755#comment-15594755 ] subhash yedugundla commented on CLOUDSTACK-9557: The following is the pull request for this https://github.com/apache/cloudstack/pull/1721 > Deploy from VMsnapshot fails with exception if source template is removed or > made private > - > > Key: CLOUDSTACK-9557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.8.0 > Environment: Any Hypervisor >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > i) Upload a template as admin user and make sure "public" is selected when > uploading it. > ii) Now login as a user to CloudPlatform and deploy a VM with the template > created in step i). > iii) Create a VM snapshot as the user for the VM in step ii). Once created > deploy a VM from the snapshot ( this will work as expected) > iv) Now login as admin again , edit the template created in step i) and > Uncheck "public". This is make the template as private ( or else delete the > template from UI) > v) Login as same user as in step ii) and try to create a VM from the same > snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594753#comment-15594753 ] ASF GitHub Bot commented on CLOUDSTACK-9557: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/1721 This should be merged after the merge of https://github.com/apache/cloudstack/pull/1664 > Deploy from VMsnapshot fails with exception if source template is removed or > made private > - > > Key: CLOUDSTACK-9557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.8.0 > Environment: Any Hypervisor >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > i) Upload a template as admin user and make sure "public" is selected when > uploading it. > ii) Now login as a user to CloudPlatform and deploy a VM with the template > created in step i). > iii) Create a VM snapshot as the user for the VM in step ii). Once created > deploy a VM from the snapshot ( this will work as expected) > iv) Now login as admin again , edit the template created in step i) and > Uncheck "public". This is make the template as private ( or else delete the > template from UI) > v) Login as same user as in step ii) and try to create a VM from the same > snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594711#comment-15594711 ] Felipe Rossi commented on CLOUDSTACK-6669: -- Hi All, We are with CS 4.5.2.1 and the BUG already persist, see bellow the usage is not update. What we need make for solve this problem ?? Cloud DB Disk Offering in Cloud DB Cloud Usage DB regards > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > Attachments: image002.png, image003.png, image004.png > > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felipe Rossi updated CLOUDSTACK-6669: - Attachment: image004.png image003.png image002.png > Support volume resize in usage server > - > > Key: CLOUDSTACK-6669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > Attachments: image002.png, image003.png, image004.png > > > volume resize events are generated in usgae_events tables. > Support to process them and update the usage records has to be added to usage > server -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594669#comment-15594669 ] ASF GitHub Bot commented on CLOUDSTACK-9339: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1659 @blueorangutan test > Virtual Routers don't handle Multiple Public Interfaces > --- > > Key: CLOUDSTACK-9339 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 >Reporter: dsclose > Labels: firewall, nat, router > > There are a series of issues with the way Virtual Routers manage multiple > public interfaces. These are more pronounced on redundant virtual router > setups. I have not attempted to examine these issues in a VPC context. > Outside of a VPC context, however, the following is expected behaviour: > * eth0 connects the router to the guest network. > * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on > eth0. > * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue > commands to the router. > * eth2 is the routers public interface. By default, a single public IP will > be setup on eth2 along with the necessary iptables and ip rules to source-NAT > guest traffic to that public IP. > * When a public IP address is assigned to the router that is on a separate > subnet to the source-NAT IP, a new interface is configured, such as eth3, and > the IP is assigned to that interface. > * This can result in eth3, eth4, eth5, etc. being created depending upon how > many public subnets the router has to work with. > The above all works. The following, however, is currently not working: > * Public interfaces should be set to DOWN on backup redundant routers. The > master.py script is responsible for setting public interfaces to UP during a > keepalived transition. Currently the check_is_up method of the CsIP class > brings all interfaces UP on both RvR. A proposed fix for this has been > discussed on the mailing list. That fix will leave public interfaces DOWN on > RvR allowing the keepalived transition to control the state of public > interfaces. Issue #1413 includes a commit that contradicts the proposed fix > so it is unclear what the current state of the code should be. > * Newly created interfaces should be set to UP on master redundant routers. > Assuming public interfaces should be default be DOWN on an RvR we need to > accommodate the fact that, as interfaces are created, no keepalived > transition occurs. This means that assigning an IP from a new public subnet > will have no effect (as the interface will be down) until the network is > restarted with a "clean up." > * Public interfaces other than eth2 do not forward traffic. There are two > iptables rules in the FORWARD chain of the filter table created for eth2 that > allow forwarding between eth2 and eth0. Equivalent rules are not created for > other public interfaces so forwarded traffic is dropped. > * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, > outbound traffic is source-NAT'd to the networks default source-NAT IP. New > connections from guests that are destined for public networks are processed > like so: > 1. Traffic is matched against the following rule in the mangle table that > marks the connection with a 0x0: > *mangle > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > 2. There are no "ip rule" statements that match a connection marked 0x0, so > the kernel routes the connection via the default gateway. That gateway is on > source-NAT subnet, so the connection is routed out of eth2. > 3. The following iptables rules are then matched in the filter table: > *filter > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A FW_OUTBOUND -j FW_EGRESS_RULES > -A FW_EGRESS_RULES -j ACCEPT > 4. Finally, the following rule is matched from the nat table, where the IP > address is the source-NAT IP: > *nat > -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67 > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594653#comment-15594653 ] ASF GitHub Bot commented on CLOUDSTACK-9557: GitHub user yvsubhash opened a pull request: https://github.com/apache/cloudstack/pull/1721 CLOUDSTACK-9557 Deploy from VMsnapshot fails with exception if source… Deploy from VMsnapshot fails with exception if source template is removed or made private You can merge this pull request into a Git repository by running: $ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9557 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1721.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1721 commit 02edceb50b8fc1d7c12d02d33bda1fa62e7c14aa Author: subhash yedugundla Date: 2016-07-14T06:43:10Z CLOUDSTACK-9557 Deploy from VMsnapshot fails with exception if source template is removed or made private > Deploy from VMsnapshot fails with exception if source template is removed or > made private > - > > Key: CLOUDSTACK-9557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.8.0 > Environment: Any Hypervisor >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > i) Upload a template as admin user and make sure "public" is selected when > uploading it. > ii) Now login as a user to CloudPlatform and deploy a VM with the template > created in step i). > iii) Create a VM snapshot as the user for the VM in step ii). Once created > deploy a VM from the snapshot ( this will work as expected) > iv) Now login as admin again , edit the template created in step i) and > Uncheck "public". This is make the template as private ( or else delete the > template from UI) > v) Login as same user as in step ii) and try to create a VM from the same > snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594636#comment-15594636 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user ProjectMoon commented on the issue: https://github.com/apache/cloudstack/pull/1623 This one hasn't been rebased in quite a while, so the packages produced will be rather old. Going to rebase this against latest 4.8. > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9491) Vmware resource: incorrect parsing of device list to find ethener index of plugged nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594596#comment-15594596 ] ASF GitHub Bot commented on CLOUDSTACK-9491: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1681 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-86 > Vmware resource: incorrect parsing of device list to find ethener index of > plugged nic > -- > > Key: CLOUDSTACK-9491 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9491 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0 > > > In VmwareResource.java, there is logic ( in findRouterEthDeviceIndex) to find > ethernet interface a mac address is associated with. > After NIC in plugged in to a Vm through vSphere, it takes some time for the > device to show up in the guest VM. > Logic loops through the device list obtained from /proc/sys/net/ipv4/conf > from the VM, and matched againest mac. > However '/proc/sys/net/ipv4/conf' is not refreshed, heve logic loops through > old device list always. > In addition there is no exception thrown and error is maked by sending -1. > Eventually, VR scripts are getting -1 as device number causing failure in > processing the scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594588#comment-15594588 ] ASF GitHub Bot commented on CLOUDSTACK-9339: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1659 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-87 > Virtual Routers don't handle Multiple Public Interfaces > --- > > Key: CLOUDSTACK-9339 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 >Reporter: dsclose > Labels: firewall, nat, router > > There are a series of issues with the way Virtual Routers manage multiple > public interfaces. These are more pronounced on redundant virtual router > setups. I have not attempted to examine these issues in a VPC context. > Outside of a VPC context, however, the following is expected behaviour: > * eth0 connects the router to the guest network. > * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on > eth0. > * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue > commands to the router. > * eth2 is the routers public interface. By default, a single public IP will > be setup on eth2 along with the necessary iptables and ip rules to source-NAT > guest traffic to that public IP. > * When a public IP address is assigned to the router that is on a separate > subnet to the source-NAT IP, a new interface is configured, such as eth3, and > the IP is assigned to that interface. > * This can result in eth3, eth4, eth5, etc. being created depending upon how > many public subnets the router has to work with. > The above all works. The following, however, is currently not working: > * Public interfaces should be set to DOWN on backup redundant routers. The > master.py script is responsible for setting public interfaces to UP during a > keepalived transition. Currently the check_is_up method of the CsIP class > brings all interfaces UP on both RvR. A proposed fix for this has been > discussed on the mailing list. That fix will leave public interfaces DOWN on > RvR allowing the keepalived transition to control the state of public > interfaces. Issue #1413 includes a commit that contradicts the proposed fix > so it is unclear what the current state of the code should be. > * Newly created interfaces should be set to UP on master redundant routers. > Assuming public interfaces should be default be DOWN on an RvR we need to > accommodate the fact that, as interfaces are created, no keepalived > transition occurs. This means that assigning an IP from a new public subnet > will have no effect (as the interface will be down) until the network is > restarted with a "clean up." > * Public interfaces other than eth2 do not forward traffic. There are two > iptables rules in the FORWARD chain of the filter table created for eth2 that > allow forwarding between eth2 and eth0. Equivalent rules are not created for > other public interfaces so forwarded traffic is dropped. > * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, > outbound traffic is source-NAT'd to the networks default source-NAT IP. New > connections from guests that are destined for public networks are processed > like so: > 1. Traffic is matched against the following rule in the mangle table that > marks the connection with a 0x0: > *mangle > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > 2. There are no "ip rule" statements that match a connection marked 0x0, so > the kernel routes the connection via the default gateway. That gateway is on > source-NAT subnet, so the connection is routed out of eth2. > 3. The following iptables rules are then matched in the filter table: > *filter > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A FW_OUTBOUND -j FW_EGRESS_RULES > -A FW_EGRESS_RULES -j ACCEPT > 4. Finally, the following rule is matched from the nat table, where the IP > address is the source-NAT IP: > *nat > -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67 > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594577#comment-15594577 ] subhash yedugundla commented on CLOUDSTACK-9557: Deploying vm from snapshot and the deploy vm from template takes the same code path and that is restricting the deployment as the we should not allow deployment from private templates. So changing this when the vmsnapshot is part of parameters for deployvm command. > Deploy from VMsnapshot fails with exception if source template is removed or > made private > - > > Key: CLOUDSTACK-9557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.8.0 > Environment: Any Hypervisor >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Steps to reproduce the issue > i) Upload a template as admin user and make sure "public" is selected when > uploading it. > ii) Now login as a user to CloudPlatform and deploy a VM with the template > created in step i). > iii) Create a VM snapshot as the user for the VM in step ii). Once created > deploy a VM from the snapshot ( this will work as expected) > iv) Now login as admin again , edit the template created in step i) and > Uncheck "public". This is make the template as private ( or else delete the > template from UI) > v) Login as same user as in step ii) and try to create a VM from the same > snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9557) Deploy from VMsnapshot fails with exception if source template is removed or made private
subhash yedugundla created CLOUDSTACK-9557: -- Summary: Deploy from VMsnapshot fails with exception if source template is removed or made private Key: CLOUDSTACK-9557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9557 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.8.0 Environment: Any Hypervisor Reporter: subhash yedugundla Fix For: 4.8.1 Steps to reproduce the issue i) Upload a template as admin user and make sure "public" is selected when uploading it. ii) Now login as a user to CloudPlatform and deploy a VM with the template created in step i). iii) Create a VM snapshot as the user for the VM in step ii). Once created deploy a VM from the snapshot ( this will work as expected) iv) Now login as admin again , edit the template created in step i) and Uncheck "public". This is make the template as private ( or else delete the template from UI) v) Login as same user as in step ii) and try to create a VM from the same snapshot ( created in step iii)). This will fail now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594502#comment-15594502
]
ASF GitHub Bot commented on CLOUDSTACK-8830:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1677
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-83
> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
>
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965)
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing: { Cmd , MgmtId:
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary&STOREUUID=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
> i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7]
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
> }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878:
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl]
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local,
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878:
> Response Received:
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8)
> (logid:8b87ab8a) Seq 8
[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594501#comment-15594501 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1678 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-84 > The router script times out resulting in failure of deployment > -- > > Key: CLOUDSTACK-9503 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.9.0 > Environment: KVM, Xen >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > > When starting the virtual router in a shared network in advance zone the > scripts on router time out. This happen as there are several sub-commands > that are consolidated in a single command. The default timeout of 2 minutes > is short. > 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) process hasn't exited > 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting > virtual router > 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) > (logid:8aedea66) The guru did not like the answers so stopping > VM[DomainRouter|r-3445-VM] > — -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9502) Target CLOUDSTACK-9386 into 4.9 release branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594500#comment-15594500 ] ASF GitHub Bot commented on CLOUDSTACK-9502: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1676 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-82 > Target CLOUDSTACK-9386 into 4.9 release branch > -- > > Key: CLOUDSTACK-9502 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9502 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9498) VR CsFile search utility methods fail when search string has char *, + etc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594503#comment-15594503 ] ASF GitHub Bot commented on CLOUDSTACK-9498: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1680 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-85 > VR CsFile search utility methods fail when search string has char *, + etc > -- > > Key: CLOUDSTACK-9498 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9498 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.8.1, 4.9.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0 > > > VR CsFile search utility methods fail when search string has char *, + etc. > These utility methods in CsFile [1] uses python regular expression module to > search a string in a file. However, if caller passes a search string, that > has chars *, +, . etc that are also happen to be express wild card / match > expression in regular expression results in exceptions from python 're' > module. > For instance searching for VPN user [2] passes "username * password *" as > search string, if password has chars the interfer with regular expression > metacharecters then search will result in exception. > 2016-09-12 13:55:48,976 configure.py add_l2tp_ipsec_user:569 Adding vpn user > murali * abcd++efgh## * > 2016-09-12 13:55:48,976 CsFile.py load:39 Reading file /etc/ppp/chap-secrets > 2016-09-12 13:55:48,976 CsFile.py searchString:140 Searching for murali * > abcd++efgh## * string > 2016-09-12 13:55:48,976 configure.py main:1020 Exception while configuring > router > Traceback (most recent call last): > File "/opt/cloud/bin/configure.py", line 965, in main > vpnuser.process() > File "/opt/cloud/bin/configure.py", line 559, in process > self.add_l2tp_ipsec_user(user, userconfig) > File "/opt/cloud/bin/configure.py", line 572, in add_l2tp_ipsec_user > userfound = file.searchString(userSearchEntry, '#') > File "/opt/cloud/bin/cs/CsFile.py", line 146, in searchString > if re.search(search, line): > File "/usr/lib/python2.7/re.py", line 142, in search > return _compile(pattern, flags).search(string) > File "/usr/lib/python2.7/re.py", line 242, in _compile > raise error, v # invalid expression > 1 > https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/cs/CsFile.py > 2 > https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py#L572 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594457#comment-15594457 ] ASF GitHub Bot commented on CLOUDSTACK-9460: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1674 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-81 > Graceful handling of Mysql server connection timeout > > > Key: CLOUDSTACK-9460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: 4.9.1.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594443#comment-15594443 ] ASF GitHub Bot commented on CLOUDSTACK-9504: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1642 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-79 > Fully support system VMs on managed storage > --- > > Key: CLOUDSTACK-9504 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.10.0.0 > > > There are three related items for this ticket: > 1) Do not permit "custom IOPS" as a parameter when creating a system offering > (throw an exception if this parameter is passed in). > 2) If you transition managed storage into maintenance mode and system VMs > were running on that managed storage, the host-side clustered file systems > (SRs on XenServer) are not removed. Remove them. > 3) Add integration tests for system VMs with managed storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594441#comment-15594441 ] ASF GitHub Bot commented on CLOUDSTACK-9317: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1623 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-77 > Disabling static NAT on many IPs can leave wrong IPs on the router > -- > > Key: CLOUDSTACK-9317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.7.0, 4.7.1, 4.7.2 >Reporter: Jeff Hair > > The current behavior of enabling or disabling static NAT will call the apply > IP associations method in the management server. The method is not > thread-safe. If it's called from multiple threads, each thread will load up > the list of public IPs in different states (add or revoke)--correct for the > thread, but not correct overall. Depending on execution order on the virtual > router, the router can end up with public IPs assigned to it that are not > supposed to be on it anymore. When another account acquires the same IP, this > of course leads to network problems. > The problem has been in CS since at least 4.2, and likely affects all > recently released versions. Affected version is set to 4.7.x because that's > what we verified against. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9451) stopVirtualMachine ignores forced parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594442#comment-15594442 ] ASF GitHub Bot commented on CLOUDSTACK-9451: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1635 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-78 > stopVirtualMachine ignores forced parameter > --- > > Key: CLOUDSTACK-9451 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9451 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.8.0, 4.9.0 >Reporter: Nathan Johnson >Priority: Minor > > As reported by Jeff Hair from the mailing list: > Hi, > I'm looking at the documentation and then the code for stopVirtualMachine. > The forced parameter is passed down into the VM manager, where it seems to > be ignored. This means that cleanupEvenIfFailed during VM stop will always > be false, despite what the API command says. Going back to commit a4f4c986 > in 2013, we can see that the forced parameter was used. During subsequent > refactoring, this seems to have vanished. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9071) stats.output.uri stops the server from starting if the uri is malformed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1559#comment-1559 ] ASF GitHub Bot commented on CLOUDSTACK-9071: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1673 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-80 > stats.output.uri stops the server from starting if the uri is malformed > --- > > Key: CLOUDSTACK-9071 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9071 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Carles Figuerola > > After inputting a malformed uri (was missing the graphite://) and restarting > the management service, the application stops at: > 2015-11-17 11:06:42,861 INFO [c.c.s.StatsCollector] > (localhost-startStop-1:null) metrics.dev.company.net is not a valid protocol > for external statistics. No statistics will be send. > No more logs are output and tomcat is up but serving a completely blank page. > When the uri has this form: (graphite://metrics.dev.company.net:2013), the > end result is very similar to the previous one > (also, the last word should be "sent") -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594326#comment-15594326 ] ASF GitHub Bot commented on CLOUDSTACK-7982: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1709 @marcaurele I had another look, you're right -- we don't have any way to see mgmt server log for Travis runs. I think rebase/squash and do a push -f to re-kick Travis run. > Storage live migration support for KVM > -- > > Key: CLOUDSTACK-7982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Marc-Aurèle Brothier > Fix For: Future > > > Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. > We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15594311#comment-15594311 ] ASF GitHub Bot commented on CLOUDSTACK-7982: Github user marcaurele commented on the issue: https://github.com/apache/cloudstack/pull/1709 @rhtyd I found the log but it doesn't give the mgmt server log output, only the job's output which got a `Command failed due to Internal Server Error` in an API response. I'll rebase & squash. > Storage live migration support for KVM > -- > > Key: CLOUDSTACK-7982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Marc-Aurèle Brothier > Fix For: Future > > > Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. > We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
