[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631766#comment-15631766 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/873 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631765#comment-15631765 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/873 @blueorangutan test > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631714#comment-15631714 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/873 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-143 > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- 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=15631681#comment-15631681 ] ASF GitHub Bot commented on CLOUDSTACK-9502: Github user murali-reddy commented on the issue: https://github.com/apache/cloudstack/pull/1676 @jburwell VR failures seen are intermittent failures we are seeing w.r.t VPC static routes, RVPC VR in other PR's as well. Not related to the patch. > 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-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=15631660#comment-15631660 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1697 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > 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-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631659#comment-15631659 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/873 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15631655#comment-15631655 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1697 @blueorangutan test > 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-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631658#comment-15631658 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/873 @blueorangutan package > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631654#comment-15631654 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1707 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-142 > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15631650#comment-15631650 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1697 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-141 > 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-8896) Allocated percentage of storage can go beyond 100%
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631648#comment-15631648 ] ASF GitHub Bot commented on CLOUDSTACK-8896: Github user karuturi commented on the issue: https://github.com/apache/cloudstack/pull/873 I tried rebasing to 4.8 but there were conflicts. rebased it against 4.9 > Allocated percentage of storage can go beyond 100% > -- > > Key: CLOUDSTACK-8896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.2, 4.6.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > This issue occurs when a volume in Ready state is moved across storage pools. > Let us say there is a data volume, volume0 in Ready state in a cluster scope > primary storage primary0. > Now, when an operation is attempted to attach this volume to a vm in another > cluster, the volume is moved to the new cluster and the asking size is zero > at this time. > you can observe logs like below with asking size 0 in the management server > logs. > 2015-09-22 08:49:02,754 DEBUG [c.c.s.StorageManagerImpl] > (Work-Job-Executor-6:ctx-27e0990a job-37/job-38 ctx-985e5ad0) > (logid:a0a97129) Checking pool: 1 for volume allocation > [Vol[8|vm=null|DATADISK]], maxSize : 3298534883328, totalAllocatedSize : > 24096276480, askingSize : 0, allocated disable threshold: 0.85 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631568#comment-15631568 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1707 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631565#comment-15631565
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1706
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been
kicked to run smoke tests
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631564#comment-15631564
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been
kicked to run smoke tests
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631566#comment-15631566 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1707 @blueorangutan package > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15631559#comment-15631559 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1697 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > 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-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631561#comment-15631561
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@blueorangutan test
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631560#comment-15631560
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1706
@blueorangutan test
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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=15631557#comment-15631557 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1697 Looks like intermittent build issue, I'll re-fire builds. @blueorangutan package > 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-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631479#comment-15631479 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1694 @nathanejohnson I'm not sure what you are doing, the build failure was due to a unit test introduced in this PR. In 4.9+ branches, the unit test did not consider the additional parameter added to the constructor signature in 4.9+ branches. The simplest fix was to simply pass null, as the unit test does not depend/use that additional parameter. Thanks for bringing this to my attention, the build is fixed on 4.9, master branches now. > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15631191#comment-15631191 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1745 Trillian test result (tid-263) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 30880 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1745-t263-kvm-centos7.zip Additional tests completed. 1 look ok, 0 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- > 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-9552) KVM Security Groups do not allow DNS over TCP egress
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631126#comment-15631126 ] ASF GitHub Bot commented on CLOUDSTACK-9552: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1713 Trillian test result (tid-264) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27737 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1713-t264-kvm-centos7.zip Test completed. 44 look ok, 4 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- ContextSuite context=TestVpcSite2SiteVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py ContextSuite context=TestVpcRemoteAccessVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py ContextSuite context=TestRVPCSite2SiteVpn>:setup | `Error` | 0.00 | test_vpc_vpn.py ContextSuite context=TestVPCRedundancy>:setup | `Error` | 0.00 | test_vpc_redundant.py test_06_download_detached_volume | `Error` | 176.26 | test_volumes.py test_04_extract_template | `Error` | 5.11 | test_templates.py test_03_delete_template | `Error` | 5.09 | test_templates.py test_01_create_template | `Error` | 35.39 | test_templates.py test_02_VPC_default_routes | Success | 266.39 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 534.65 | test_vpc_router_nics.py test_09_delete_detached_volume | Success | 15.41 | test_volumes.py test_08_resize_volume | Success | 15.40 | test_volumes.py test_07_resize_fail | Success | 20.46 | test_volumes.py test_05_detach_volume | Success | 100.25 | test_volumes.py test_04_delete_attached_volume | Success | 10.20 | test_volumes.py test_03_download_attached_volume | Success | 15.29 | test_volumes.py test_02_attach_volume | Success | 45.09 | test_volumes.py test_01_create_volume | Success | 711.69 | test_volumes.py test_deploy_vm_multiple | Success | 278.69 | 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 | 423.94 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.16 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.93 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.15 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.81 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.86 | test_vm_life_cycle.py test_02_start_vm | Success | 10.19 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.33 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 105.88 | 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_02_edit_template | Success | 90.18 | test_templates.py test_10_destroy_cpvm | Success | 161.70 | test_ssvm.py test_09_destroy_ssvm | Success | 168.78 | test_ssvm.py test_08_reboot_cpvm | Success | 131.92 | test_ssvm.py test_07_reboot_ssvm | Success | 133.68 | test_ssvm.py test_06_stop_cpvm | Success | 131.75 | test_ssvm.py test_05_stop_ssvm | Success | 163.71 | test_ssvm.py test_04_cpvm_internals | Success | 1.30 | test_ssvm.py test_03_ssvm_internals | Success | 3.71 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 16.32 | test_snapshots.py test_04_change_offering_small | Success | 211.10 | 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.13 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py test_09_reboot_router | Success | 45.37 | test_routers.py test_08_start_router | Success | 40.36 | test_routers.py test_07_stop_router | Success | 10.16 | test_routers.py test_06_router_advanced | Success | 0.06 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.73 | test_routers.py test_03_restart_network_cleanup | Success | 60.55 | test_routers.py test_02_router_internal_adv | Success | 1.08 | test_routers.py test_01_router_internal_basic | Success | 0.58 | test_routers.py test_router_dns_guestipquery | Success | 78.56 | test_router_dns.py test_router_dns_externalipquery | Success | 0.08 | test_r
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631040#comment-15631040 ] ASF GitHub Bot commented on CLOUDSTACK-9553: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1714 Trillian test result (tid-265) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 25519 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1714-t265-kvm-centos7.zip Test completed. 42 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 385.43 | test_vpc_redundant.py test_01_vpc_site2site_vpn | Success | 176.06 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.49 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 261.55 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 291.08 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 563.60 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 521.85 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1373.19 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 566.18 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 764.69 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.48 | test_volumes.py test_08_resize_volume | Success | 15.46 | test_volumes.py test_07_resize_fail | Success | 20.68 | test_volumes.py test_06_download_detached_volume | Success | 15.37 | test_volumes.py test_05_detach_volume | Success | 100.27 | test_volumes.py test_04_delete_attached_volume | Success | 10.30 | test_volumes.py test_03_download_attached_volume | Success | 15.48 | test_volumes.py test_02_attach_volume | Success | 73.81 | test_volumes.py test_01_create_volume | Success | 712.15 | test_volumes.py test_deploy_vm_multiple | Success | 248.92 | 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.97 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.32 | test_vm_life_cycle.py test_08_migrate_vm | Success | 41.14 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.18 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.87 | test_vm_life_cycle.py test_03_reboot_vm | Success | 126.17 | test_vm_life_cycle.py test_02_start_vm | Success | 10.20 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.41 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 116.70 | test_templates.py test_08_list_system_templates | Success | 0.05 | test_templates.py test_07_list_public_templates | Success | 0.06 | test_templates.py test_05_template_permissions | Success | 0.11 | test_templates.py test_04_extract_template | Success | 5.15 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.15 | test_templates.py test_01_create_template | Success | 85.99 | test_templates.py test_10_destroy_cpvm | Success | 136.99 | test_ssvm.py test_09_destroy_ssvm | Success | 193.85 | test_ssvm.py test_08_reboot_cpvm | Success | 101.88 | test_ssvm.py test_07_reboot_ssvm | Success | 134.07 | test_ssvm.py test_06_stop_cpvm | Success | 131.85 | test_ssvm.py test_05_stop_ssvm | Success | 133.71 | test_ssvm.py test_04_cpvm_internals | Success | 1.21 | test_ssvm.py test_03_ssvm_internals | Success | 3.42 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 17.56 | test_snapshots.py test_04_change_offering_small | Success | 209.98 | test_service_offerings.py test_03_delete_service_offering | Success | 0.09 | test_service_offerings.py test_02_edit_service_offering | Success | 0.12 | test_service_offerings.py test_01_create_service_offering | Success | 0.19 | test_service_offerings.py test_02_sys_template_ready | Success | 0.12 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py test_09_reboot_router | Success | 35.51 | 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.05 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.67 | test_routers.py test_03_restart
[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630996#comment-15630996 ] ASF GitHub Bot commented on CLOUDSTACK-8326: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1743 Trillian test result (tid-262) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 26169 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1743-t262-kvm-centos7.zip Test completed. 47 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 375.02 | test_vpc_redundant.py test_01_vpc_site2site_vpn | Success | 170.23 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.28 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 261.29 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 308.48 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 531.07 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 519.04 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1312.05 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 585.61 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 766.40 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.65 | test_volumes.py test_08_resize_volume | Success | 15.40 | test_volumes.py test_07_resize_fail | Success | 20.50 | test_volumes.py test_06_download_detached_volume | Success | 15.31 | test_volumes.py test_05_detach_volume | Success | 100.26 | test_volumes.py test_04_delete_attached_volume | Success | 10.21 | test_volumes.py test_03_download_attached_volume | Success | 15.30 | test_volumes.py test_02_attach_volume | Success | 45.57 | test_volumes.py test_01_create_volume | Success | 726.80 | test_volumes.py test_deploy_vm_multiple | Success | 304.38 | test_vm_life_cycle.py test_deploy_vm | Success | 0.04 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.04 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 27.16 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.23 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.98 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.12 | test_vm_life_cycle.py test_06_destroy_vm | Success | 126.03 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.90 | test_vm_life_cycle.py test_02_start_vm | Success | 10.18 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.42 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 75.66 | 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 | 5.27 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.18 | test_templates.py test_01_create_template | Success | 65.60 | test_templates.py test_10_destroy_cpvm | Success | 166.70 | test_ssvm.py test_09_destroy_ssvm | Success | 163.70 | test_ssvm.py test_08_reboot_cpvm | Success | 131.63 | test_ssvm.py test_07_reboot_ssvm | Success | 133.61 | test_ssvm.py test_06_stop_cpvm | Success | 131.77 | test_ssvm.py test_05_stop_ssvm | Success | 133.92 | test_ssvm.py test_04_cpvm_internals | Success | 1.24 | test_ssvm.py test_03_ssvm_internals | Success | 3.36 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.25 | test_snapshots.py test_04_change_offering_small | Success | 239.69 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py test_01_create_service_offering | Success | 0.13 | test_service_offerings.py test_02_sys_template_ready | Success | 0.13 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.18 | test_secondary_storage.py test_09_reboot_router | Success | 40.49 | 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_04_restart_network_wo_cleanup | Success | 5.73 | test_routers.py test_03_restart_
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630976#comment-15630976 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1578 Trillian test result (tid-260) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 38810 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1578-t260-vmware-55u3.zip Test completed. 46 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_vpc_site2site_vpn | `Error` | 517.00 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 743.47 | test_vpc_vpn.py ContextSuite context=TestRVPCSite2SiteVpn>:teardown | `Error` | 889.61 | test_vpc_vpn.py test_01_VPC_nics_after_destroy | `Error` | 127.62 | test_vpc_router_nics.py test_01_vpc_remote_access_vpn | Success | 176.74 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 391.31 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 713.94 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1550.04 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 821.10 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 841.51 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1448.10 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 25.93 | test_volumes.py test_06_download_detached_volume | Success | 95.90 | test_volumes.py test_05_detach_volume | Success | 110.33 | test_volumes.py test_04_delete_attached_volume | Success | 20.27 | test_volumes.py test_03_download_attached_volume | Success | 20.32 | test_volumes.py test_02_attach_volume | Success | 58.90 | test_volumes.py test_01_create_volume | Success | 517.87 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.21 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 232.27 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 201.60 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 161.75 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 314.12 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.85 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.27 | test_vm_life_cycle.py test_08_migrate_vm | Success | 91.19 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.17 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.16 | test_vm_life_cycle.py test_02_start_vm | Success | 20.26 | test_vm_life_cycle.py test_01_stop_vm | Success | 10.15 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 387.76 | 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 | 15.32 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.15 | test_templates.py test_01_create_template | Success | 241.83 | test_templates.py test_10_destroy_cpvm | Success | 236.93 | test_ssvm.py test_09_destroy_ssvm | Success | 238.89 | test_ssvm.py test_08_reboot_cpvm | Success | 186.62 | test_ssvm.py test_07_reboot_ssvm | Success | 188.91 | test_ssvm.py test_06_stop_cpvm | Success | 206.93 | test_ssvm.py test_05_stop_ssvm | Success | 204.31 | test_ssvm.py test_04_cpvm_internals | Success | 1.22 | test_ssvm.py test_03_ssvm_internals | Success | 3.40 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 66.45 | test_snapshots.py test_04_change_offering_small | Success | 127.22 | test_service_offerings.py test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py test_02_edit_service_offering | Success | 0.11 | test_service_offerings.py test_01_create_service_offering | Success | 0.11 | test_service_offerings.py test_02_sys_template_ready | Success | 0.16 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py test_09_reboot_router | Success | 176.20 | test_routers.py test_08_start_router | Success | 125.83 | test_routers.py
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630779#comment-15630779 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1578 Trillian test result (tid-258) Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6 Total time taken: 33873 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1578-t258-xenserver-65sp1.zip Test completed. 45 look ok, 3 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_05_rvpc_multi_tiers | `Failure` | 552.72 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 1367.04 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 658.75 | test_vpc_redundant.py test_01_snapshot_root_disk | `Failure` | 26.60 | test_snapshots.py test_04_rvpc_privategw_static_routes | `Failure` | 224.03 | test_privategw_acl.py test_01_vpc_site2site_vpn | Success | 316.86 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 172.09 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 614.99 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 367.14 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 701.96 | test_vpc_router_nics.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 841.40 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 1092.08 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 20.89 | test_volumes.py test_08_resize_volume | Success | 121.70 | test_volumes.py test_07_resize_fail | Success | 116.36 | test_volumes.py test_06_download_detached_volume | Success | 25.47 | test_volumes.py test_05_detach_volume | Success | 100.30 | test_volumes.py test_04_delete_attached_volume | Success | 15.30 | test_volumes.py test_03_download_attached_volume | Success | 20.39 | test_volumes.py test_02_attach_volume | Success | 10.79 | test_volumes.py test_01_create_volume | Success | 392.84 | test_volumes.py test_03_delete_vm_snapshots | Success | 280.29 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 221.62 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 100.79 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 188.63 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.95 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.27 | test_vm_life_cycle.py test_08_migrate_vm | Success | 61.51 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.15 | test_vm_life_cycle.py test_06_destroy_vm | Success | 15.24 | test_vm_life_cycle.py test_03_reboot_vm | Success | 20.28 | test_vm_life_cycle.py test_02_start_vm | Success | 25.30 | test_vm_life_cycle.py test_01_stop_vm | Success | 30.35 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 151.50 | test_templates.py test_08_list_system_templates | Success | 0.04 | test_templates.py test_07_list_public_templates | Success | 0.05 | test_templates.py test_05_template_permissions | Success | 0.08 | test_templates.py test_04_extract_template | Success | 5.22 | test_templates.py test_03_delete_template | Success | 5.30 | test_templates.py test_02_edit_template | Success | 90.12 | test_templates.py test_01_create_template | Success | 96.06 | test_templates.py test_10_destroy_cpvm | Success | 201.77 | test_ssvm.py test_09_destroy_ssvm | Success | 199.93 | test_ssvm.py test_08_reboot_cpvm | Success | 151.90 | test_ssvm.py test_07_reboot_ssvm | Success | 174.11 | test_ssvm.py test_06_stop_cpvm | Success | 167.04 | test_ssvm.py test_05_stop_ssvm | Success | 139.07 | test_ssvm.py test_04_cpvm_internals | Success | 1.12 | test_ssvm.py test_03_ssvm_internals | Success | 3.42 | 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_04_change_offering_small | Success | 96.25 | test_service_offerings.py test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py test_02_edit_service_offering | Success | 0.12 | test_service_offerings.py test_01_create_service_offering | Success | 0.12 | test_service_offerings.py test_02_sys_template_ready | Success | 0.15 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.22 | test_secondary_storage.py test_01_scale_vm | Success | 5.26 | test_scale_vm.py test_09_reboot
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630716#comment-15630716 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1694 @rhtyd I have an issue with circular dependencies trying to make the test work with the new signature. In order to initialize the StoragePoolMonitor, I need a DataStoreManagerImpl type, and this is defined in cloud-engine-storage . I cannot add cloud-engine-storage as a maven dependency of cloud-server because this in turn depends on cloud-secondary-storage , which in turn depends on cloud-server. I'm not sure what the best path forward is, but unfortunately I don't think I can get this resolved today (no pun intended). > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630484#comment-15630484 ] ASF GitHub Bot commented on CLOUDSTACK-8326: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1743 Trillian test result (tid-254) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27962 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1743-t254-kvm-centos7.zip Test completed. 46 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_02_vpc_privategw_static_routes | `Failure` | 148.77 | test_privategw_acl.py test_06_download_detached_volume | `Error` | 15.25 | test_volumes.py test_01_vpc_site2site_vpn | Success | 165.61 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 101.29 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 286.42 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 309.30 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 573.88 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 523.53 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1331.37 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 599.60 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 766.25 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1376.00 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.53 | test_volumes.py test_08_resize_volume | Success | 15.37 | test_volumes.py test_07_resize_fail | Success | 20.43 | test_volumes.py test_05_detach_volume | Success | 100.20 | test_volumes.py test_04_delete_attached_volume | Success | 10.20 | test_volumes.py test_03_download_attached_volume | Success | 15.27 | test_volumes.py test_02_attach_volume | Success | 73.82 | test_volumes.py test_01_create_volume | Success | 720.17 | test_volumes.py test_deploy_vm_multiple | Success | 283.54 | 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.61 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.18 | test_vm_life_cycle.py test_08_migrate_vm | Success | 66.02 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.12 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.78 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.82 | test_vm_life_cycle.py test_02_start_vm | Success | 10.19 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.35 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 156.23 | 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.05 | test_templates.py test_04_extract_template | Success | 5.31 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.12 | test_templates.py test_01_create_template | Success | 116.14 | test_templates.py test_10_destroy_cpvm | Success | 167.39 | test_ssvm.py test_09_destroy_ssvm | Success | 165.24 | test_ssvm.py test_08_reboot_cpvm | Success | 131.61 | test_ssvm.py test_07_reboot_ssvm | Success | 134.51 | test_ssvm.py test_06_stop_cpvm | Success | 161.96 | test_ssvm.py test_05_stop_ssvm | Success | 165.01 | test_ssvm.py test_04_cpvm_internals | Success | 1.25 | test_ssvm.py test_03_ssvm_internals | Success | 5.18 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py test_01_snapshot_root_disk | Success | 16.39 | test_snapshots.py test_04_change_offering_small | Success | 243.08 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py test_01_create_service_offering | Success | 0.42 | test_service_offerings.py test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.21 | test_secondary_storage.py test_09_reboot_router | Success | 60.55 | test_routers.py test_08_start_router | Success | 45.53 | test_routers.py test_07_stop_router | Success | 10.24 | test_routers.py test_06_router_advanced | Success | 0.06 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py te
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630458#comment-15630458 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1694 Thanks for sharing @nathanejohnson in case you've already fixed it, can you send a PR? Otherwise, it's late for me, I'll have a look first in the morning. > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630443#comment-15630443 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1578 Trillian test result (tid-259) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27269 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1578-t259-kvm-centos7.zip Test completed. 47 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_template | `Error` | 95.95 | test_templates.py test_01_vpc_site2site_vpn | Success | 185.72 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.18 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 256.54 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 254.44 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 569.20 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 496.25 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1472.28 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 566.21 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 739.88 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1336.08 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.50 | test_volumes.py test_08_resize_volume | Success | 15.38 | test_volumes.py test_07_resize_fail | Success | 20.43 | test_volumes.py test_06_download_detached_volume | Success | 15.27 | test_volumes.py test_05_detach_volume | Success | 100.28 | test_volumes.py test_04_delete_attached_volume | Success | 10.18 | test_volumes.py test_03_download_attached_volume | Success | 15.30 | test_volumes.py test_02_attach_volume | Success | 43.60 | test_volumes.py test_01_create_volume | Success | 721.82 | test_volumes.py test_deploy_vm_multiple | Success | 299.08 | 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 | 27.82 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py test_08_migrate_vm | Success | 35.85 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.17 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.95 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.98 | test_vm_life_cycle.py test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py test_01_stop_vm | Success | 35.36 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 201.45 | 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 | 5.17 | test_templates.py test_03_delete_template | Success | 5.10 | test_templates.py test_02_edit_template | Success | 90.18 | test_templates.py test_10_destroy_cpvm | Success | 161.47 | test_ssvm.py test_09_destroy_ssvm | Success | 164.21 | test_ssvm.py test_08_reboot_cpvm | Success | 131.67 | test_ssvm.py test_07_reboot_ssvm | Success | 134.60 | test_ssvm.py test_06_stop_cpvm | Success | 161.92 | test_ssvm.py test_05_stop_ssvm | Success | 138.84 | test_ssvm.py test_04_cpvm_internals | Success | 1.27 | test_ssvm.py test_03_ssvm_internals | Success | 4.56 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py test_01_snapshot_root_disk | Success | 16.36 | test_snapshots.py test_04_change_offering_small | Success | 209.65 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.07 | test_service_offerings.py test_01_create_service_offering | Success | 0.12 | test_service_offerings.py test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py test_09_reboot_router | Success | 51.14 | test_routers.py test_08_start_router | Success | 35.36 | test_routers.py test_07_stop_router | Success | 15.18 | test_routers.py test_06_router_advanced | Success | 0.08 | test_routers.py test_05_router_basic | Success | 0.04 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.79 | test_routers.py test_03_restart_
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630424#comment-15630424 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1694 @rhtyd It appears that rolling this forward to 4.9 et al has broken builds. The signature of the CreateStoragePool constructor changed between 4.8 and 4.9. https://github.com/apache/cloudstack/blob/4.8/server/src/com/cloud/storage/listener/StoragePoolMonitor.java#L52 That's the 4.8 version https://github.com/apache/cloudstack/blob/4.9/server/src/com/cloud/storage/listener/StoragePoolMonitor.java#L57 That's the 4.9 version, which takes 3 parameters. When building I get the following error: [ERROR] /server/test/com/cloud/storage/listener/StoragePoolMonitorTest.java:[49,29] error: constructor StoragePoolMonitor in class StoragePoolMonitor cannot be applied to given types; > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15630322#comment-15630322 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user ProjectMoon commented on the issue: https://github.com/apache/cloudstack/pull/1744 In the JIRA ticket, it's at least reported that this is happening on 4.8 as well. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15630146#comment-15630146 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1697 @blueorangutan could you send logs? I just verified that I could build a centos 7 rpm from this branch, can't reproduce the failure. Thanks! > 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-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=15630040#comment-15630040 ] ASF GitHub Bot commented on CLOUDSTACK-9460: Github user nathanejohnson commented on the issue: https://github.com/apache/cloudstack/pull/1674 Code LGTM > 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-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629935#comment-15629935 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1694 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-136 > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629938#comment-15629938 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1707 Packaging result: ✖centos6 ✖centos7 ✖debian. JID-140 > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15629937#comment-15629937 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1697 Packaging result: ✖centos6 ✖centos7 ✖debian. JID-137 > 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-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629936#comment-15629936
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1706
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-139
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629853#comment-15629853
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1727
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-135
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629842#comment-15629842 ] ASF GitHub Bot commented on CLOUDSTACK-9403: Github user prashanthvarma commented on the issue: https://github.com/apache/cloudstack/pull/1579 @rhtyd As I mentioned in the earlier comments, this feature PR has dependency with our other open feature PR #1578. Thus, we re-based this PR (2 commits) on top of that PR (2 commits) as we don't know which PR will go in first. One option: Once PR #1578 has been merged into master, we will re-base this PR with latest master. Thus, we will have only two commits in this PR. Let me know, if you want us to do this in a different way. > Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin > test coverage > > > Key: CLOUDSTACK-9403 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > This is first phase of support of Shared Network in cloudstack through > NuageVsp Network Plugin. A shared network is a type of virtual network that > is shared between multiple accounts i.e. a shared network can be accessed by > virtual machines that belong to many different accounts. This basic > functionality will be supported with the below common use case: > - shared network can be used for monitoring purposes. A shared network can be > assigned to a domain and can be used for monitoring VMs belonging to all > accounts in that domain. > - Public accessible of shared Network. > With the current implementation with NuageVsp plugin, It support over-lapping > of Ip address, Public Access and also adding Ip ranges in shared Network. > In VSD, it is implemented in below manner: > - In order to have tenant isolation for shared networks, we will have to > create a Shared L3 Subnet for each shared network, and instantiate it across > the relevant enterprises. A shared network will only exist under an > enterprise when it is needed, so when the first VM is spinned under that ACS > domain inside that shared network. > - For public shared Network it will also create a floating ip subnet pool in > VSD along with all the things mentioned in above point. > PR contents: > 1) Support for shared networks with tenant isolation on master with Nuage VSP > SDN Plugin. > 2) Support of shared network with publicly accessible ip ranges. > 2) Marvin test coverage for shared networks on master with Nuage VSP SDN > Plugin. > 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 4) PEP8 & PyFlakes compliance with our Marvin test code. > Test Results are:- > Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain > in a shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a > shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same > domain but in a ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for user in the same > domain but in a different ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for regular user in a shared > network with scope=account ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for a domain admin users in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for other users in a shared > network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for admin user in a domain in > a shared network wit
[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629841#comment-15629841 ] ASF GitHub Bot commented on CLOUDSTACK-9402: Github user prashanthvarma commented on the issue: https://github.com/apache/cloudstack/pull/1580 @rhtyd @jburwell As I mentioned in the earlier comments, this feature PR has dependency with our other open feature PR #1578. Thus, we re-based this PR (2 commits) on top of that PR (2 commits) as we don't know which PR will go in first. One option: Once PR #1578 has been merged into master, we will re-base this PR with latest master. Thus, we will have only two commits in this PR. Let me know, if you want us to do this in a different way. > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networ
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629799#comment-15629799 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1707 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629798#comment-15629798
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1706
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you
posted as I make progress.
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629795#comment-15629795
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1706
@blueorangutan package
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629794#comment-15629794 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1707 @blueorangutan package > Add Watchdog timer to KVM Instances > --- > > Key: CLOUDSTACK-9397 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: kvm, libvirt, watchdog > > A Watchdog timer can be used by the hypervisor to verify if an Instance is > still alive. If not, for example due to a kernel panic the HV can reset the > Instance so that it boots again. > Inside the Instance the 'watchdog' daemon has to run to provide this. If the > Watchdog is not running the HV can't verify if the Instance has crashed. > This is supported by Libvirt and Qemu and can be configured in the XML: > https://libvirt.org/formatdomain.html#elementsWatchdog -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629785#comment-15629785 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit b75e6958150f76a0c8f9cbfa24301da2d7cd2c6a in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b75e695 ] Merge pull request #1728 from shapeblue/4.9_9551 CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoidMove java tmp dir to cloudstack-agent's path to avoid noexec on /tmp * pr/1728: CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp Signed-off-by: Rohit Yadav > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629781#comment-15629781 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 32a397aa9357c409de7561a8c68a469c3bf3c52a in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=32a397a ] CLOUDSTACK-9509: Host Connects Without Storage KVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629783#comment-15629783 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629786#comment-15629786 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit b75e6958150f76a0c8f9cbfa24301da2d7cd2c6a in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b75e695 ] Merge pull request #1728 from shapeblue/4.9_9551 CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoidMove java tmp dir to cloudstack-agent's path to avoid noexec on /tmp * pr/1728: CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp Signed-off-by: Rohit Yadav > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629782#comment-15629782 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit bd85e5b4da0be5177f7fd766641c75dabaf9c45d in cloudstack's branch refs/heads/master from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bd85e5b ] CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629784#comment-15629784 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629777#comment-15629777 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit b75e6958150f76a0c8f9cbfa24301da2d7cd2c6a in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b75e695 ] Merge pull request #1728 from shapeblue/4.9_9551 CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoidMove java tmp dir to cloudstack-agent's path to avoid noexec on /tmp * pr/1728: CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp Signed-off-by: Rohit Yadav > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629775#comment-15629775 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629779#comment-15629779 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit b75e6958150f76a0c8f9cbfa24301da2d7cd2c6a in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b75e695 ] Merge pull request #1728 from shapeblue/4.9_9551 CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoidMove java tmp dir to cloudstack-agent's path to avoid noexec on /tmp * pr/1728: CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp Signed-off-by: Rohit Yadav > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629776#comment-15629776 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629771#comment-15629771 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 32a397aa9357c409de7561a8c68a469c3bf3c52a in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=32a397a ] CLOUDSTACK-9509: Host Connects Without Storage KVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629774#comment-15629774 ] ASF GitHub Bot commented on CLOUDSTACK-9551: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1728 > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629773#comment-15629773 ] ASF subversion and git services commented on CLOUDSTACK-9551: - Commit bd85e5b4da0be5177f7fd766641c75dabaf9c45d in cloudstack's branch refs/heads/4.9 from [~abhi_shapeblue] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bd85e5b ] CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629725#comment-15629725 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1694 > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629720#comment-15629720 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 32a397aa9357c409de7561a8c68a469c3bf3c52a in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=32a397a ] CLOUDSTACK-9509: Host Connects Without Storage KVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15629753#comment-15629753 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1697 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > 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-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=15629749#comment-15629749 ] ASF GitHub Bot commented on CLOUDSTACK-4858: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1697 @blueorangutan package > 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-9552) KVM Security Groups do not allow DNS over TCP egress
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629746#comment-15629746 ] ASF GitHub Bot commented on CLOUDSTACK-9552: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1713 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > KVM Security Groups do not allow DNS over TCP egress > > > Key: CLOUDSTACK-9552 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.8.0, 4.9.0 > Environment: KVM Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: dns, dnssec, security-groups > Fix For: Future > > > When egress filtering is configured all outbound traffic is blocked unless > configured otherwise. > With the exception that UDP/53 DNS is allowed implicitly by the Security > Groups. > Many DNS responses are larger then 4k, with DNSSEC for example and require > TCP to be allowed. > The Security Groups should also allow TCP/53 when egress filtering is > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629747#comment-15629747 ] ASF GitHub Bot commented on CLOUDSTACK-9553: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1714 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9552) KVM Security Groups do not allow DNS over TCP egress
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629741#comment-15629741 ] ASF GitHub Bot commented on CLOUDSTACK-9552: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1713 @blueorangutan test > KVM Security Groups do not allow DNS over TCP egress > > > Key: CLOUDSTACK-9552 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9552 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.8.0, 4.9.0 > Environment: KVM Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: dns, dnssec, security-groups > Fix For: Future > > > When egress filtering is configured all outbound traffic is blocked unless > configured otherwise. > With the exception that UDP/53 DNS is allowed implicitly by the Security > Groups. > Many DNS responses are larger then 4k, with DNSSEC for example and require > TCP to be allowed. > The Security Groups should also allow TCP/53 when egress filtering is > configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9553) Usage event is not getting recorded for snapshots in a specific scenario
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629740#comment-15629740 ] ASF GitHub Bot commented on CLOUDSTACK-9553: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1714 @blueorangutan test > Usage event is not getting recorded for snapshots in a specific scenario > > > Key: CLOUDSTACK-9553 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9553 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.9.0 > Environment: vmware 4.5.1 >Reporter: subhash yedugundla > Fix For: Future > > > 1. Create a scheduled snapshot of the volume > 2. Delete the snapshot schedule before the run of the usage job for the day. > 3. The usage job completes successfully but there is a error message "post > process snapshot failed" > 4. The snapshot.create event is captured in the event table, but not in the > usage event table -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9554) Juniper Contrail plug-in is publishing events to wrong message bus
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629739#comment-15629739 ] ASF GitHub Bot commented on CLOUDSTACK-9554: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1715 I don't have the specific hardware to trigger and run regression tests on the changes. Can we get a second code review and then we can merge this. /cc @karuturi @jburwell and others? > Juniper Contrail plug-in is publishing events to wrong message bus > -- > > Key: CLOUDSTACK-9554 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9554 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: eventbus >Affects Versions: 4.9.0 > Environment: Citrix Xenserver with juniper contrail. >Reporter: subhash yedugundla > Fix For: 4.10.0.0 > > > Juniper contrail plugin is publishing events to internal message bus instead > of event bus. which can lead to a deadlock in the following scenario > 1. Create a VM in cloudstack with xenserver > 2. Create firewall rules on contrail for the same > 3. Delete the vm from xenserver directly. > 4. Next power state sync cycle would create a deadlock -- 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=15629735#comment-15629735 ] ASF GitHub Bot commented on CLOUDSTACK-9557: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1721 @yvsubhash can you check why Travis/Jenkins failed. Is it possible to merge your changes in PR #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 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-8676) Deploy user instance from vm snapshot for VMware hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629731#comment-15629731 ] ASF GitHub Bot commented on CLOUDSTACK-8676: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1664 @sateesh-chodapuneedi can you fix the conflicts and rebase against latest master. Thanks. > Deploy user instance from vm snapshot for VMware hypervisor > --- > > Key: CLOUDSTACK-8676 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8676 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: Future > > > Currently, ACS provides the ability to deploy a VM from a template or ISO. > However, ACS does not provide the ability to deploy a VM(s) directly from a > VM snapshot. > VM snapshots are stored in the primary storage and have a hierarchical or > parent/child relationship. The requirement would be to provide the ability to > deploy user instances from selected VM snapshots. Additionally, any VM > snapshot in the hierarchy can be deployed concurrently. > Even though this can be supported and applicable to all hypervisors, to > start with this feature is supported only for VMware hypervisor. > Feature specification is at > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Deploy+instance+from+VM+snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629728#comment-15629728 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1694 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629723#comment-15629723 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9559) Deleting zone without deleting the secondary storage under the zone should not be allowed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629727#comment-15629727 ] ASF GitHub Bot commented on CLOUDSTACK-9559: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1725 @yvsubhash can you check the Travis/Jenkins failures, why would we want to keep a secondary storage around while deleting a zone? > 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] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629721#comment-15629721 ] ASF subversion and git services commented on CLOUDSTACK-9509: - Commit 68f22e2a438c5ec1b7a390632cb94256bfdb6938 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68f22e2 ] Merge pull request #1694 from shapeblue/kvm-no-storage-failfast CLOUDSTACK-9509: Host Connects Without StorageKVM hosts on shared storage failure was accepted by mgmt server with the host state as Up, even though there was no primary/shared storage available on it. This patch offers a quick fix by throwing an exception in the storage monitor which connects storage pool on host. The failure is trapped by agent manager that disconnects the agent without any investigation. Based on Lab tests, KVM agent may take upto 2 minutes to attempt NFS mount when the storage is inaccessible (firewalled, or shutdown) before returning back with an error. It is safe to assume that this won't add pressure on mgmt server due to several reconnection attempts, and KVM agent would retry reconnection every 2 minutes. For such KVM hosts, where failure happens due to storage issues; they will be briefly put in Alert state but will be mostly be in Connecting state during which the KVM host attempts to mount/reconfigure NFS storage pool. /cc @jburwell @karuturi @blueorangutan package * pr/1694: CLOUDSTACK-9509: Host Connects Without Storage Signed-off-by: Rohit Yadav > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629718#comment-15629718
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1727
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you
posted as I make progress.
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629715#comment-15629715
]
ASF GitHub Bot commented on CLOUDSTACK-9539:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1727
Thanks @nvazquez I'll kick some tests
@blueorangutan package
> Support changing Service offering for instance with VM Snapshots
>
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which
> have vm snapshots. In that case, previously taken snapshots (if reverted)
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way
> snapshot can be reverted to original state even though service offering can
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}}
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629717#comment-15629717 ] ASF GitHub Bot commented on CLOUDSTACK-9551: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1728 Merging this based on code review and regression test results. The failures are known intermittent failures and not caused by the changes in the PR. > Pull KVM agent's tmp folder usage within its own folder structure > - > > Key: CLOUDSTACK-9551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.7.1, 4.9.1.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > > We ran into an issue today where the sysadmins wanted to put /tmp on its own > mount and set the "noexec" mount flag as a security measure. This is > incompatible with the CloudStack KVM agent, because it stores JNA tmp files > here and Java is unable to map into these objects. To get around this we > moved the agent's temp dir to live with the agent files, which seems like a > reasonable thing to do regardless of whether you're trying to secure /tmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9572) Snapshot on primary storage not cleaned up after Storage migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629710#comment-15629710 ] ASF GitHub Bot commented on CLOUDSTACK-9572: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1740 @yvsubhash can you fix the conflicts and rebase against latest 4.8/4.9. Thanks. > Snapshot on primary storage not cleaned up after Storage migration > -- > > Key: CLOUDSTACK-9572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.8.0 > Environment: Xen Server >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Issue Description > === > 1. Create an instance on the local storage on any host > 2. Create a scheduled snapshot of the volume: > 3. Wait until ACS created the snapshot. ACS is creating a snapshot on local > storage and is transferring this snapshot to secondary storage. But the > latest snapshot on local storage will stay there. This is as expected. > 4. Migrate the instance to another XenServer host with ACS UI and Storage > Live Migration > 5. The Snapshot on the old host on local storage will not be cleaned up and > is staying on local storage. So local storage will fill up with unneeded > snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629709#comment-15629709 ] ASF GitHub Bot commented on CLOUDSTACK-9183: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1744 I think this is an issue only in 4.7 branch, the file has been removed in recent branches. @PaulAngus can share his insights on this as well. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8326) Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP Debian Wheezy specific
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629705#comment-15629705 ] ASF GitHub Bot commented on CLOUDSTACK-8326: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1743 Previous Trillian test job failed due to backend issue, I've rekicked them now. > Bug in cloudstack virtual router (KVM) in Simple zone with public ips / DHCP > Debian Wheezy specific > --- > > Key: CLOUDSTACK-8326 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8326 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Virtual Router >Affects Versions: 4.3.2 > Environment: Ubuntu 12.04.5 for Host > Debian Squeeze for VR >Reporter: Ivan A Kudryavtsev >Assignee: Wido den Hollander > Fix For: Future, 4.10.0.0, 4.9.2.0 > > > I've found bug in DHCP component of VR 4.3.2. The bug is completely described > at: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717217 > DHCP responses with bad checksum. As a result, dhcp client unable to get > lease: "dhcpd: 5 bad udp checksums in 5 packets" > Hotfix is: > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM > --checksum-fill > on VR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9509) KVM Hosts connect with no storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629700#comment-15629700 ] ASF GitHub Bot commented on CLOUDSTACK-9509: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1694 Merging this based on tests results and review, the failures caused in VPC/VR related tests are known intermittent issues. > KVM Hosts connect with no storage > - > > Key: CLOUDSTACK-9509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.8.1, 4.10.0.0, 4.9.1.0 > > > KVM hosts on shared storage failure was accepted by mgmt server with the > host state as Up, even though there was no primary/shared storage available > on it. They fail the ModifyStoragePoolCommand, but the management server > continues on with adding SSH keys and marking them as up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15629663#comment-15629663 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1745 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > 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-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=15629659#comment-15629659 ] ASF GitHub Bot commented on CLOUDSTACK-9503: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1745 The following will run an additional component tests: @blueorangutan test centos7 kvm-centos7 component/test_routers.py component/test_acl_isolatednetwork.py component/test_add_remove_network.py component/test_network_offering.py component/test_persistent_networks.py > 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-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629648#comment-15629648
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1542
@jburwell @nvazquez we have the capability to run any additional tests
using blueorangutan now, can you suggest what tests we should run. The syntax
would be following: (to be commented)
test [mgmt server os] [hypervisor] [list of comma separated additional
tests will full paths, but related to test/integration directory]
or, test matrix [list of comma separated tests]
Example:
test matrix component/test_routers.py component/test_users.py
component/test_accounts.py
I'm also working towards including several of the existing component tests
(runnable with simulator) to Travis. We're now able to run all the smoke tests
on all three major hypervisors now with BlueOrangutan and Trillian/Jenkins, the
next steps is to run/optimize component tests.
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
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=15629630#comment-15629630
]
ASF GitHub Bot commented on CLOUDSTACK-8830:
Github user blueorangutan commented on the issue:
https://github.com/apache/cloudstack/pull/1677
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you
posted as I make progress.
> [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] (DirectAg
[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=15629621#comment-15629621
]
ASF GitHub Bot commented on CLOUDSTACK-8830:
Github user rhtyd commented on the issue:
https://github.com/apache/cloudstack/pull/1677
@blueorangutan package
> [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 80-6161487240196259878: Processing: {
[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629612#comment-15629612 ] ASF GitHub Bot commented on CLOUDSTACK-9403: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1579 @prashanthvarma can you squash the commits please, I see 4 here. At least squash the ones related, i.e. one for the feature and one for the integration test. > Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin > test coverage > > > Key: CLOUDSTACK-9403 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > This is first phase of support of Shared Network in cloudstack through > NuageVsp Network Plugin. A shared network is a type of virtual network that > is shared between multiple accounts i.e. a shared network can be accessed by > virtual machines that belong to many different accounts. This basic > functionality will be supported with the below common use case: > - shared network can be used for monitoring purposes. A shared network can be > assigned to a domain and can be used for monitoring VMs belonging to all > accounts in that domain. > - Public accessible of shared Network. > With the current implementation with NuageVsp plugin, It support over-lapping > of Ip address, Public Access and also adding Ip ranges in shared Network. > In VSD, it is implemented in below manner: > - In order to have tenant isolation for shared networks, we will have to > create a Shared L3 Subnet for each shared network, and instantiate it across > the relevant enterprises. A shared network will only exist under an > enterprise when it is needed, so when the first VM is spinned under that ACS > domain inside that shared network. > - For public shared Network it will also create a floating ip subnet pool in > VSD along with all the things mentioned in above point. > PR contents: > 1) Support for shared networks with tenant isolation on master with Nuage VSP > SDN Plugin. > 2) Support of shared network with publicly accessible ip ranges. > 2) Marvin test coverage for shared networks on master with Nuage VSP SDN > Plugin. > 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 4) PEP8 & PyFlakes compliance with our Marvin test code. > Test Results are:- > Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain > in a shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a > shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same > domain but in a ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for user in the same > domain but in a different ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for regular user in a shared > network with scope=account ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for a domain admin users in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for other users in a shared > network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for admin user in a domain in > a shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status > : SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in > a shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_sc
[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629607#comment-15629607 ] ASF GitHub Bot commented on CLOUDSTACK-9402: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1580 @prashanthvarma I still see 4 different commits, can you squash them? At least squash the similar ones together, so we can effectively get two commits one around the feature and one around the marvin test. > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networks with different combinations of Static NAT > service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Static NAT service > providers ... === TestName: test_
[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629415#comment-15629415 ] ASF GitHub Bot commented on CLOUDSTACK-9402: Github user prashanthvarma commented on the issue: https://github.com/apache/cloudstack/pull/1580 @jburwell @rhtyd I have rebased this PR with latest master, and squashed commits. > Nuage VSP Plugin : Support for underlay features (Source & Static NAT to > underlay) including Marvin test coverage on master > --- > > Key: CLOUDSTACK-9402 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Affects Versions: 4.10.0.0 >Reporter: Mani Prashanth Varma Manthena >Assignee: Nick Livens > > Support for underlay features (Source & Static NAT to underlay) with Nuage > VSP SDN Plugin including Marvin test coverage for corresponding Source & > Static NAT features on master. Moreover, our Marvin tests are written in such > a way that they can validate our supported feature set with both Nuage VSP > SDN platform's overlay and underlay infra. > PR contents: > 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN > Plugin. > 3) Marvin test coverage for Source & Static NAT to underlay on master with > Nuage VSP SDN Plugin. > 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 5) PEP8 & PyFlakes compliance with our Marvin test code. > Our Marvin test code PEP8 & PyFlakes compliance: > CloudStack$ > CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py > CloudStack$ > CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py > CloudStack$ > Validations: > 1) Underlay infra (Source & Static NAT to underlay) > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_source_nat.py > Test results: > Test Nuage VSP Isolated networks with different combinations of Source NAT > service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Source NAT service > providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Source NAT functionality for Isolated network by performing > (wget) traffic tests to the ... === TestName: > test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality for VPC network by performing (wget) > traffic tests to the Internet ... === TestName: > test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with different Egress > Firewall/Network ACL rules by performing (wget) ... === TestName: > test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM NIC operations by performing > (wget) traffic tests to the ... === TestName: > test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with VM migration by performing > (wget) traffic tests to the Internet ... === TestName: > test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS === > ok > Test Nuage VSP Source NAT functionality with network restarts by performing > (wget) traffic tests to the ... === TestName: > test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS === > ok > -- > Ran 8 tests in 13360.858s > OK > Marvin test run: > nosetests --with-marvin --marvin-config=nuage.cfg > plugins/nuagevsp/test_nuage_static_nat.py > Test results: > Test Nuage VSP Public IP Range creation and deletion ... === TestName: > test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range > creation and deletion ... === TestName: > test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS === > ok > Test Nuage VSP Isolated networks with different combinations of Static NAT > service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks > | Status : SUCCESS === > ok > Test Nuage VSP VPC networks with different combinations of Static NAT service > providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : > SUCCESS === > ok > Test Nuage VSP Static NAT functionality for Isolate
[jira] [Commented] (CLOUDSTACK-9572) Snapshot on primary storage not cleaned up after Storage migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629244#comment-15629244 ] ASF GitHub Bot commented on CLOUDSTACK-9572: Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1740 > Wait until ACS created the snapshot. ACS is creating a snapshot on local storage and is transferring this snapshot to secondary storage. But the latest snapshot on local storage will stay there. This is as expected. Why is it expected that latest snapshot be present on the primary storage after it has been copied? Shouldn't it be deleted? > Snapshot on primary storage not cleaned up after Storage migration > -- > > Key: CLOUDSTACK-9572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.8.0 > Environment: Xen Server >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > Issue Description > === > 1. Create an instance on the local storage on any host > 2. Create a scheduled snapshot of the volume: > 3. Wait until ACS created the snapshot. ACS is creating a snapshot on local > storage and is transferring this snapshot to secondary storage. But the > latest snapshot on local storage will stay there. This is as expected. > 4. Migrate the instance to another XenServer host with ACS UI and Storage > Live Migration > 5. The Snapshot on the old host on local storage will not be cleaned up and > is staying on local storage. So local storage will fill up with unneeded > snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629136#comment-15629136 ] ASF GitHub Bot commented on CLOUDSTACK-9403: Github user prashanthvarma commented on the issue: https://github.com/apache/cloudstack/pull/1579 @jburwell @rhtyd I have rebased this PR with latest master, and squashed commits. > Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin > test coverage > > > Key: CLOUDSTACK-9403 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > This is first phase of support of Shared Network in cloudstack through > NuageVsp Network Plugin. A shared network is a type of virtual network that > is shared between multiple accounts i.e. a shared network can be accessed by > virtual machines that belong to many different accounts. This basic > functionality will be supported with the below common use case: > - shared network can be used for monitoring purposes. A shared network can be > assigned to a domain and can be used for monitoring VMs belonging to all > accounts in that domain. > - Public accessible of shared Network. > With the current implementation with NuageVsp plugin, It support over-lapping > of Ip address, Public Access and also adding Ip ranges in shared Network. > In VSD, it is implemented in below manner: > - In order to have tenant isolation for shared networks, we will have to > create a Shared L3 Subnet for each shared network, and instantiate it across > the relevant enterprises. A shared network will only exist under an > enterprise when it is needed, so when the first VM is spinned under that ACS > domain inside that shared network. > - For public shared Network it will also create a floating ip subnet pool in > VSD along with all the things mentioned in above point. > PR contents: > 1) Support for shared networks with tenant isolation on master with Nuage VSP > SDN Plugin. > 2) Support of shared network with publicly accessible ip ranges. > 2) Marvin test coverage for shared networks on master with Nuage VSP SDN > Plugin. > 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory). > 4) PEP8 & PyFlakes compliance with our Marvin test code. > Test Results are:- > Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain > in a shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a > shared network with ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same > domain but in a ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | > Status : SUCCESS === > ok > Valiate that ROOT admin is NOT able to deploy a VM for user in the same > domain but in a different ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for regular user in a shared > network with scope=account ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS > === > ok > Valiate that ROOT admin is able to deploy a VM for a domain admin users in a > shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for other users in a shared > network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : > SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for admin user in a domain in > a shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status > : SUCCESS === > ok > Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in > a shared network with scope=all ... === TestName: > test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainuser | Status : > SUCCESS === > ok > Valiate that
[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628797#comment-15628797
]
ASF GitHub Bot commented on CLOUDSTACK-9379:
Github user nvazquez commented on the issue:
https://github.com/apache/cloudstack/pull/1542
That's great, thanks!
> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware
> hypervisor. Current behaviour supports enabling/desabling global nested
> virtualization by modifying global config {{'vmware.nested.virtualization'}}.
> It is wished to improve this feature, having control at VM level instead of a
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present,
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628736#comment-15628736 ] Rajani Karuturi commented on CLOUDSTACK-8353: - great. Thanks [~andrija] > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Rajani Karuturi > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628621#comment-15628621 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1578 @rhtyd a Trillian-Jenkins matrix job (centos6 mgmt + xs65sp1, centos7 mgmt + vmware55u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests > Nuage VSP Plugin : Support for InternalDns including Marvin test coverage > - > > Key: CLOUDSTACK-9401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > Supporting Internal Dns by using Dns service provider as Virtual Router but > Dhcp provider will be NuageVsp. The idea is here is to keep using Internal > Dns service of cloudstack when network provider is some other vendor. > A sample network offering will be like below one:- > Service Provider > DHCP NuageVsp > DNSVirtualRouter/VpcVirtualRouter > UserDataVirtualRouter/VpcVirtualRouter > Virtual Networking NuageVsp > SourceNat NuageVsp > StaticNat NuageVsp > NetworkAcl/FirewallNuageVsp > Testrun:- > Verify InternalDns on Isolated Network ... === TestName: > test_01_Isolated_Network_with_zone | Status : SUCCESS === > ok > Verify InternalDns on Isolated Network with ping by hostname ... === > TestName: test_02_Isolated_Network | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network ... === > TestName: test_03_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network with ping VM > ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify InternalDns on VPC Network ... === TestName: > test_05_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > Verify InternalDns on VPC Network by ping with hostname ... === TestName: > test_06_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > -- > Ran 6 tests in 5736.562s > OK > cloudstack$ pep8 --max-line-length=150 test_internal_dns.py > cloudstack$ pyflakes test_internal_dns.py > cloudstack$ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9401) Nuage VSP Plugin : Support for InternalDns including Marvin test coverage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628619#comment-15628619 ] ASF GitHub Bot commented on CLOUDSTACK-9401: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1578 @blueorangutan test matrix > Nuage VSP Plugin : Support for InternalDns including Marvin test coverage > - > > Key: CLOUDSTACK-9401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9401 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Network Controller >Reporter: Rahul Singal >Assignee: Nick Livens > > Supporting Internal Dns by using Dns service provider as Virtual Router but > Dhcp provider will be NuageVsp. The idea is here is to keep using Internal > Dns service of cloudstack when network provider is some other vendor. > A sample network offering will be like below one:- > Service Provider > DHCP NuageVsp > DNSVirtualRouter/VpcVirtualRouter > UserDataVirtualRouter/VpcVirtualRouter > Virtual Networking NuageVsp > SourceNat NuageVsp > StaticNat NuageVsp > NetworkAcl/FirewallNuageVsp > Testrun:- > Verify InternalDns on Isolated Network ... === TestName: > test_01_Isolated_Network_with_zone | Status : SUCCESS === > ok > Verify InternalDns on Isolated Network with ping by hostname ... === > TestName: test_02_Isolated_Network | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network ... === > TestName: test_03_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify update NetworkDomain for InternalDns on Isolated Network with ping VM > ... === TestName: test_04_Update_Network_with_Domain | Status : SUCCESS === > ok > Verify InternalDns on VPC Network ... === TestName: > test_05_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > Verify InternalDns on VPC Network by ping with hostname ... === TestName: > test_06_VPC_Network_With_InternalDns | Status : SUCCESS === > ok > -- > Ran 6 tests in 5736.562s > OK > cloudstack$ pep8 --max-line-length=150 test_internal_dns.py > cloudstack$ pyflakes test_internal_dns.py > cloudstack$ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628582#comment-15628582 ] Andrija Panic commented on CLOUDSTACK-8353: --- I saw that part of code earlier, but this again doenst solve the issue - it references only "Windows 2008" as guest OS, not "Windows PV" - and to be honest no-one probably uses "Windows 2008" as OS type, because its not virtio (we are on KVM) - and also code only references (if I read code correclty, Im not developer) only centos 6.5 and 7, not i.e. Ubuntu as host etc. We have actually develop solution internally, similar code (and NOT yet tested(, but we are not checking host OS in the code (we assume all hots support hyperv enligment flags), so not sure if this is convinient for commnunity (if it passes our internal tests first...) I will try to update here, or have one of our devs comment after we do some testing. Thx Rajani > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Rajani Karuturi > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628558#comment-15628558 ] Andrija Panic commented on CLOUDSTACK-8353: --- Hi Rajani, no it's not solving the issue - we have 1 DC upgraded to ACS 4.8.0.1 and using "Windows PV" as the OS type - and I can see there are zero of additional flags for HyperV Enligmnet enabled. So this is not addressed (at least properly) in 4.7 release as mentioned in separate ticket. I will try to change OS type to "Windows 2008" in ACS, to see if this is addressed with this kind of OS type. > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Rajani Karuturi > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628556#comment-15628556 ] Rajani Karuturi commented on CLOUDSTACK-8353: - I think the connecting bit is commented. you might have to uncomment code at https://github.com/apache/cloudstack/blob/master/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1976-L1982 > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reassigned CLOUDSTACK-8353: --- Assignee: Rajani Karuturi > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Rajani Karuturi > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8353: Assignee: (was: Bharat Kumar) > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15628508#comment-15628508 ] Rajani Karuturi commented on CLOUDSTACK-8353: - [~andrija] Can you take a look at CLOUDSTACK-9004? looks like this is a duplicate > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
