[jira] [Commented] (CLOUDSTACK-10352) XenServer: Support online storage migration from non-managed to managed storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1645#comment-1645 ] ASF GitHub Bot commented on CLOUDSTACK-10352: - blueorangutan commented on issue #2502: [CLOUDSTACK-10352] XenServer: Support online migration of a virtual disk from non-managed to managed storage URL: https://github.com/apache/cloudstack/pull/2502#issuecomment-380311941 Trillian test result (tid-2487) Environment: vmware-65 (x2), Advanced Networking with Mgmt server 7 Total time taken: 51499 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2502-t2487-vmware-65.zip Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py Intermitten failure detected: /marvin/tests/smoke/test_reset_vm_on_reboot.py Intermitten failure detected: /marvin/tests/smoke/test_router_dhcphosts.py Intermitten failure detected: /marvin/tests/smoke/test_router_dns.py Intermitten failure detected: /marvin/tests/smoke/test_router_dnsservice.py Intermitten failure detected: /marvin/tests/smoke/test_routers_iptables_default_policy.py Intermitten failure detected: /marvin/tests/smoke/test_routers_network_ops.py Intermitten failure detected: /marvin/tests/smoke/test_routers.py Intermitten failure detected: /marvin/tests/smoke/test_scale_vm.py Intermitten failure detected: /marvin/tests/smoke/test_secondary_storage.py Intermitten failure detected: /marvin/tests/smoke/test_service_offerings.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py Intermitten failure detected: /marvin/tests/smoke/test_templates.py Intermitten failure detected: /marvin/tests/smoke/test_usage.py Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_router_nics.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Smoke tests completed. 46 look OK, 21 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- ContextSuite context=TestResetVmOnReboot>:setup | `Error` | 0.00 | test_reset_vm_on_reboot.py ContextSuite context=TestRouterDHCPHosts>:setup | `Error` | 0.00 | test_router_dhcphosts.py ContextSuite context=TestRouterDHCPOpts>:setup | `Error` | 0.00 | test_router_dhcphosts.py ContextSuite context=TestChangeServiceOfferingForVmWithSnapshots>:setup | `Error` | 0.00 | test_vm_snapshots.py ContextSuite context=TestVmSnapshot>:setup | `Error` | 0.00 | test_vm_snapshots.py ContextSuite context=TestRouterDns>:setup | `Error` | 0.00 | test_router_dns.py ContextSuite context=TestRouterDnsService>:setup | `Error` | 0.00 | test_router_dnsservice.py ContextSuite context=TestRouterIpTablesPolicies>:setup | `Error` | 0.00 | test_routers_iptables_default_policy.py ContextSuite context=TestVPCIpTablesPolicies>:setup | `Error` | 0.00 | test_routers_iptables_default_policy.py test_01_isolate_network_FW_PF_default_routes_egress_true | `Error` | 0.15 | test_routers_network_ops.py test_02_isolate_network_FW_PF_default_routes_egress_false | `Error` | 0.14 | test_routers_network_ops.py ContextSuite context=TestRedundantIsolateNetworks>:setup | `Error` | 1.29 | test_routers_network_ops.py ContextSuite context=TestRouterServices>:setup | `Error` | 0.00 | test_routers.py ContextSuite context=TestScaleVm>:setup | `Error` | 0.00 | test_scale_vm.py test_01_sys_vm_start | `Failure` | 0.12 | test_secondary_storage.py test_02_sys_template_ready | `Failure` | 0.08 | test_secondary_storage.py ContextSuite context=TestCpuCapServiceOfferings>:teardown | `Error` | 0.00 | test_service_offerings.py ContextSuite context=TestServiceOfferings>:setup | `Error` | 0.16 | test_service_offerings.py ContextSuite context=TestSnapshotRootDisk>:setup | `Error` | 0.00 | test_snapshots.py test_01_list_sec_storage_vm | `Failure` | 0.03 | test_ssvm.py test_02_list_cpvm_vm | `Failure` | 0.03 | test_ssvm.py test_03_ssvm_internals | `Failure` | 0.03 | test_ssvm.py test_04_cpvm_internals | `Failure` | 0.03 | test_ssvm.py test_05_stop_ssvm | `Failure` | 0.03 | test_ssvm.py test_06_stop_cpvm | `Failure` | 0.03 | test_ssvm.py test_07_reboot_ssvm | `Failure` | 0.03 | test_ssvm.py test_08_reboot_cpvm | `Failure` | 0.03 | test_ssvm.py test_09_destroy_ssvm | `Failure`
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432782#comment-16432782
]
ASF GitHub Bot commented on CLOUDSTACK-10323:
-
nitin-maharana commented on a change in pull request #2486: [CLOUDSTACK-10323]
Allow changing disk offering during volume migration
URL: https://github.com/apache/cloudstack/pull/2486#discussion_r175389327
##
File path: server/src/main/java/com/cloud/storage/VolumeApiServiceImpl.java
##
@@ -2097,26 +2079,102 @@ public Volume migrateVolume(MigrateVolumeCmd cmd) {
}
}
-return orchestrateMigrateVolume(vol.getId(), destPool.getId(),
liveMigrateVolume);
+return orchestrateMigrateVolume(vol, destPool, liveMigrateVolume,
newDiskOffering);
}
-private Volume orchestrateMigrateVolume(long volumeId, long destPoolId,
boolean liveMigrateVolume) {
-VolumeVO vol = _volsDao.findById(volumeId);
-assert (vol != null);
-StoragePool destPool =
(StoragePool)dataStoreMgr.getDataStore(destPoolId, DataStoreRole.Primary);
-assert (destPool != null);
+/**
+ * Retrieve the new disk offering UUID that might be sent to replace the
current one in the volume being migrated.
+ * If no disk offering UUID is provided we return null. Otherwise, we
perform the following checks.
+ *
+ * Is the disk offering UUID entered valid? If not, an {@link
InvalidParameterValueException} is thrown;
+ * If the disk offering was already removed, we thrown an {@link
InvalidParameterValueException} is thrown;
+ * We then check if the user executing the operation has access to
the given disk offering.
+ *
+ *
+ * If all checks pass, we move forward returning the disk offering object.
+ */
+private DiskOfferingVO retrieveAndValidateNewDiskOffering(MigrateVolumeCmd
cmd) {
+String newDiskOfferingUuid = cmd.getNewDiskOfferingUuid();
+if (org.apache.commons.lang.StringUtils.isBlank(newDiskOfferingUuid)) {
+return null;
+}
+DiskOfferingVO newDiskOffering =
_diskOfferingDao.findByUuid(newDiskOfferingUuid);
+if (newDiskOffering == null) {
+throw new InvalidParameterValueException(String.format("The disk
offering informed is not valid [id=%s].", newDiskOfferingUuid));
+}
+if (newDiskOffering.getRemoved() != null) {
+throw new InvalidParameterValueException(String.format("We cannot
assign a removed disk offering [id=%s] to a volume. ",
newDiskOffering.getUuid()));
+}
+Account caller = CallContext.current().getCallingAccount();
+_accountMgr.checkAccess(caller, newDiskOffering);
+return newDiskOffering;
+}
+
+/**
+ * Performs the validations required for replacing the disk offering while
migrating the volume of storage. If no new disk offering is provided, we do not
execute any validation.
+ * If a disk offering is informed, we then proceed with the following
checks.
+ *
Review comment:
Same here.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change disk offering when volume is migrated to different type of storage
> pool.
> ---
>
> Key: CLOUDSTACK-10323
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.12
>Reporter: Rafael Weingärtner
>Assignee: Rafael Weingärtner
>Priority: Major
>
> This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240),
> which provided root admins an override mechanism to move volumes between
> storage systems types (local/shared) even when the disk offering would not
> allow such operation. To complete the work, we will now provide a way for
> administrators to enter a new disk offering that can reflect the new
> placement of the volume. We will add an extra parameter to allow the root
> admin inform a new disk offering for the volume. Therefore, when the volume
> is being migrated, it will be possible to replace the disk offering to
> reflect the new placement of the volume.
> The API method will have the following parameters:
> * storageid (required)
> * volumeid (required)
> * livemigrate(optional)
> * newdiskofferingid (optional) – this is the new parameter
> The expected behavior is the following:
> * If “newdiskofferingid”
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432515#comment-16432515 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - blueorangutan commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-380153586 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1898 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10344) Sometimes a bug happens when moving ACL rules (changing their order with drag and drop)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432491#comment-16432491 ] ASF GitHub Bot commented on CLOUDSTACK-10344: - rafaelweingartner commented on issue #2511: [CLOUDSTACK-10344] bug when moving ACL rules (change order with drag and drop) URL: https://github.com/apache/cloudstack/pull/2511#issuecomment-380148227 @nitin-maharana do you approve this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Sometimes a bug happens when moving ACL rules (changing their order with drag > and drop) > > > Key: CLOUDSTACK-10344 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10344 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > An error is happening in certain conditions, such as when you have only 2 ACL > rules and you move the last one to the top. There are other conditions, for > instance, when moving ACLs that are in a sequence of numbers without gaps. > Example, rules: > number | rule > 1 - rule A > 2 - rule D > 3 - rule B > 4 - rule C > 5 - rule E > It is not possible to move "rule C" in position 2, 1, and 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10344) Sometimes a bug happens when moving ACL rules (changing their order with drag and drop)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432489#comment-16432489 ] ASF GitHub Bot commented on CLOUDSTACK-10344: - rafaelweingartner commented on issue #2511: [CLOUDSTACK-10344] bug when moving ACL rules (change order with drag and drop) URL: https://github.com/apache/cloudstack/pull/2511#issuecomment-380148227 @nitin-maharana did you approve this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Sometimes a bug happens when moving ACL rules (changing their order with drag > and drop) > > > Key: CLOUDSTACK-10344 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10344 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > An error is happening in certain conditions, such as when you have only 2 ACL > rules and you move the last one to the top. There are other conditions, for > instance, when moving ACLs that are in a sequence of numbers without gaps. > Example, rules: > number | rule > 1 - rule A > 2 - rule D > 3 - rule B > 4 - rule C > 5 - rule E > It is not possible to move "rule C" in position 2, 1, and 3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432473#comment-16432473 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - rafaelweingartner commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-380144240 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10214) Unable to remove local primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432475#comment-16432475 ] ASF GitHub Bot commented on CLOUDSTACK-10214: - blueorangutan commented on issue #2390: [CLOUDSTACK-10214] Unable to remove local primary storage URL: https://github.com/apache/cloudstack/pull/2390#issuecomment-380144503 @rafaelweingartner a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Unable to remove local primary storage > --- > > Key: CLOUDSTACK-10214 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10214 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0, 4.9.3.0 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > When enabling the use of local storage ACS will automatically load all local > storage configured in the Host and start using them as primary storage to > deploy user VMs (if the service offering allows to do so). However, if the > operator wants to remove the local storage ACS will throw an exception saying > that the removal of local storage is not allowed.Therefore, if one wants to > remove a local storage, he/she needs to do a manual intervention in the > database and hosts. > This limitation was removed, as it was only a logical restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432171#comment-16432171 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-380077312 @PaulAngus a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10352) XenServer: Support online storage migration from non-managed to managed storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432169#comment-16432169 ] ASF GitHub Bot commented on CLOUDSTACK-10352: - PaulAngus commented on issue #2502: [CLOUDSTACK-10352] XenServer: Support online migration of a virtual disk from non-managed to managed storage URL: https://github.com/apache/cloudstack/pull/2502#issuecomment-380077171 @blueorangutan test matrix This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer: Support online storage migration from non-managed to managed > storage > --- > > Key: CLOUDSTACK-10352 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10352 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer > Environment: XenServer >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski >Priority: Major > Fix For: 4.12.0.0 > > > Allow a user to online migrate a volume from non-managed storage to managed > storage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10352) XenServer: Support online storage migration from non-managed to managed storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432170#comment-16432170 ] ASF GitHub Bot commented on CLOUDSTACK-10352: - blueorangutan commented on issue #2502: [CLOUDSTACK-10352] XenServer: Support online migration of a virtual disk from non-managed to managed storage URL: https://github.com/apache/cloudstack/pull/2502#issuecomment-380077303 @PaulAngus a Trillian-Jenkins matrix job (centos6 mgmt + xs71, centos7 mgmt + vmware65, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer: Support online storage migration from non-managed to managed > storage > --- > > Key: CLOUDSTACK-10352 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10352 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer > Environment: XenServer >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski >Priority: Major > Fix For: 4.12.0.0 > > > Allow a user to online migrate a volume from non-managed storage to managed > storage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432167#comment-16432167 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - PaulAngus commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-380076997 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432168#comment-16432168 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - blueorangutan commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-380077038 @PaulAngus a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432166#comment-16432166 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - PaulAngus commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-380076824 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432128#comment-16432128 ] ASF subversion and git services commented on CLOUDSTACK-10226: -- Commit bbc92046655bc528846090eddf1fc38abd2da90a in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=bbc9204 ] [CLOUDSTACK-10226] CloudStack is not importing Local storage properly (#2401) * [CLOUDSTACK-10226] CloudStack is not importing Local storage properly CloudStack is importing as Local storage any XenServer SR that is of type LVM or EXT. This causes a problem when one wants to use both Direct attach storage and local storage. Moreover, CloudStack was not importing all of the local storage that a host has available when local storage is enabled. It was only importing the First SR it sees. To fix the first problem we started ignoring SRs that have the flag shared=true when discovering local storages. SRs configured to be shared are used as direct attached storage, and therefore should not be imported again as local ones. To fix the second problem, we started loading all Local storage and importing them accordingly to ACS. * Cleanups and formatting > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432127#comment-16432127 ] ASF subversion and git services commented on CLOUDSTACK-10226: -- Commit bbc92046655bc528846090eddf1fc38abd2da90a in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=bbc9204 ] [CLOUDSTACK-10226] CloudStack is not importing Local storage properly (#2401) * [CLOUDSTACK-10226] CloudStack is not importing Local storage properly CloudStack is importing as Local storage any XenServer SR that is of type LVM or EXT. This causes a problem when one wants to use both Direct attach storage and local storage. Moreover, CloudStack was not importing all of the local storage that a host has available when local storage is enabled. It was only importing the First SR it sees. To fix the first problem we started ignoring SRs that have the flag shared=true when discovering local storages. SRs configured to be shared are used as direct attached storage, and therefore should not be imported again as local ones. To fix the second problem, we started loading all Local storage and importing them accordingly to ACS. * Cleanups and formatting > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432126#comment-16432126
]
ASF GitHub Bot commented on CLOUDSTACK-10226:
-
rafaelweingartner closed pull request #2401: [CLOUDSTACK-10226] CloudStack is
not importing Local storage properly
URL: https://github.com/apache/cloudstack/pull/2401
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
index 19670b2066e..4a9001b27da 100644
---
a/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
+++
b/plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
@@ -51,8 +51,10 @@
import org.apache.cloudstack.storage.to.TemplateObjectTO;
import org.apache.cloudstack.storage.to.VolumeObjectTO;
+import org.apache.commons.collections.CollectionUtils;
import org.apache.commons.collections.MapUtils;
import org.apache.commons.io.FileUtils;
+import org.apache.commons.lang3.BooleanUtils;
import org.apache.log4j.Logger;
import org.apache.xmlrpc.XmlRpcException;
import org.joda.time.Duration;
@@ -173,7 +175,7 @@
* used to describe what type of resource a storage device is of
*/
public enum SRType {
-EXT, FILE, ISCSI, ISO, LVM, LVMOHBA, LVMOISCSI,
+EXT, ISO, LVM, LVMOHBA, LVMOISCSI,
/**
* used for resigning metadata (like SR UUID and VDI UUID when a
* particular storage manager is installed on a XenServer host (for
back-end snapshots to work))
@@ -761,11 +763,6 @@ protected VDI cloudVDIcopy(final Connection conn, final
VDI vdi, final SR sr, in
final HashMap vmMetaDatum = new HashMap();
try {
final Map vm_map = VM.getAllRecords(conn); // USE
-// THIS TO
-// GET ALL
-// VMS
-// FROM A
-// CLUSTER
if (vm_map != null) {
for (final VM.Record record : vm_map.values()) {
if (record.isControlDomain || record.isASnapshot ||
record.isATemplate) {
@@ -2274,16 +2271,11 @@ public HostStatsEntry getHostStats(final Connection
conn, final GetHostStatsComm
}
protected HashMap
getHostVmStateReport(final Connection conn) {
-
-// TODO : new VM sync model does not require a cluster-scope report, we
-// need to optimize
-// the report accordingly
final HashMap vmStates = new
HashMap();
Map vm_map = null;
for (int i = 0; i < 2; i++) {
try {
-vm_map = VM.getAllRecords(conn); // USE THIS TO GET ALL VMS
FROM
-// A CLUSTER
+vm_map = VM.getAllRecords(conn);
break;
} catch (final Throwable e) {
s_logger.warn("Unable to get vms", e);
@@ -2652,76 +2644,6 @@ public String getLabel() {
return result;
}
-protected SR getLocalEXTSR(final Connection conn) {
-try {
-final Map map = SR.getAllRecords(conn);
-if (map != null && !map.isEmpty()) {
-for (final Map.Entry entry : map.entrySet()) {
-final SR.Record srRec = entry.getValue();
-if (SRType.FILE.equals(srRec.type) ||
SRType.EXT.equals(srRec.type)) {
-final Set pbds = srRec.PBDs;
-if (pbds == null) {
-continue;
-}
-for (final PBD pbd : pbds) {
-final Host host = pbd.getHost(conn);
-if (!isRefNull(host) &&
host.getUuid(conn).equals(_host.getUuid())) {
-if (!pbd.getCurrentlyAttached(conn)) {
-pbd.plug(conn);
-}
-final SR sr = entry.getKey();
-sr.scan(conn);
-return sr;
-}
-}
-}
-}
-}
-} catch (final XenAPIException e) {
-final String msg = "Unable to get local EXTSR in host:" +
_host.getUuid() + e.toString();
-s_logger.warn(msg);
-} catch (final XmlRpcException e) {
-final String msg = "Unable to get local EXTSR in host:" +
_host.getUuid() + e.getCause(
[jira] [Resolved] (CLOUDSTACK-10226) CloudStack is not importing Local storage properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10226. - Resolution: Fixed > CloudStack is not importing Local storage properly > --- > > Key: CLOUDSTACK-10226 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10226 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > CloudStack is importing as Local storage any XenServer SR that is of type LVM > or EXT. This causes a problem when one wants to use both Direct attach > storage and local storage. Moreover, CloudStack was not importing all of the > local storage that a host has available when local storage is enabled. It was > only importing the First SR it sees. > To fix the first problem we started ignoring SRs that have the flag > shared=true when discovering local storages. SRs configured to be shared are > used as direct attached storage, and therefore should not be imported again > as local ones. > To fix the second problem, we started loading all Local storage and importing > them accordingly to ACS. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10301. - Resolution: Fixed Fix Version/s: 4.12 > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432123#comment-16432123 ] ASF subversion and git services commented on CLOUDSTACK-10301: -- Commit b08f9e053ff301d59dc81283704be37dc1871905 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b08f9e0 ] [CLOUDSTACK-10301] Allow updating the network ACL list name and Description (#2462) * [CLOUDSTACK-10301] Allow updating the network ACL list name and description * Fixes suggested by Daan > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432121#comment-16432121
]
ASF GitHub Bot commented on CLOUDSTACK-10301:
-
rafaelweingartner closed pull request #2462: [CLOUDSTACK-10301] Allow updating
the network ACL list name and Description
URL: https://github.com/apache/cloudstack/pull/2462
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/api/src/main/java/com/cloud/network/vpc/NetworkACLService.java
b/api/src/main/java/com/cloud/network/vpc/NetworkACLService.java
index dd7c862d46b..378b15ce940 100644
--- a/api/src/main/java/com/cloud/network/vpc/NetworkACLService.java
+++ b/api/src/main/java/com/cloud/network/vpc/NetworkACLService.java
@@ -22,6 +22,7 @@
import org.apache.cloudstack.api.command.user.network.ListNetworkACLListsCmd;
import org.apache.cloudstack.api.command.user.network.ListNetworkACLsCmd;
import org.apache.cloudstack.api.command.user.network.UpdateNetworkACLItemCmd;
+import org.apache.cloudstack.api.command.user.network.UpdateNetworkACLListCmd;
import com.cloud.exception.ResourceUnavailableException;
import com.cloud.utils.Pair;
@@ -38,7 +39,7 @@
NetworkACL getNetworkACL(long id);
/**
- * List NetworkACLs by Id/Name/Network or Vpc it belongs to
+ * List NetworkACLs by Id/Name/Network or VPC it belongs to
*/
Pair, Integer>
listNetworkACLs(ListNetworkACLListsCmd cmd);
@@ -87,6 +88,6 @@
*/
boolean replaceNetworkACLonPrivateGw(long aclId, long privateGatewayId)
throws ResourceUnavailableException;
-NetworkACL updateNetworkACL(Long id, String customId, Boolean forDisplay);
+NetworkACL updateNetworkACL(UpdateNetworkACLListCmd
updateNetworkACLListCmd);
}
diff --git
a/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLListCmd.java
b/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLListCmd.java
index aa1f557e72b..22eaf2180ca 100644
---
a/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLListCmd.java
+++
b/api/src/main/java/org/apache/cloudstack/api/command/user/network/UpdateNetworkACLListCmd.java
@@ -31,8 +31,7 @@
import com.cloud.network.vpc.NetworkACL;
import com.cloud.user.Account;
-@APICommand(name = "updateNetworkACLList", description = "Updates network ACL
list", responseObject = SuccessResponse.class, since = "4.4",
-requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
+@APICommand(name = "updateNetworkACLList", description = "Updates network ACL
list", responseObject = SuccessResponse.class, since = "4.4",
requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
public class UpdateNetworkACLListCmd extends BaseAsyncCustomIdCmd {
public static final Logger s_logger =
Logger.getLogger(UpdateNetworkACLListCmd.class.getName());
private static final String s_name = "updatenetworkacllistresponse";
@@ -44,9 +43,16 @@
@Parameter(name = ApiConstants.ID, type = CommandType.UUID, entityType =
NetworkACLResponse.class, required = true, description = "the ID of the network
ACL")
private Long id;
-@Parameter(name = ApiConstants.FOR_DISPLAY, type = CommandType.BOOLEAN,
description = "an optional field, whether to the display the list to the end
user or not", since = "4.4", authorized = {RoleType.Admin})
+@Parameter(name = ApiConstants.FOR_DISPLAY, type = CommandType.BOOLEAN,
description = "an optional field, whether to the display the list to the end
user or not", since = "4.4", authorized = {
+RoleType.Admin})
private Boolean display;
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING,
description = "Name of the network ACL list")
+private String name;
+
+@Parameter(name = ApiConstants.DESCRIPTION, type = CommandType.STRING,
description = "Description of the network ACL list")
+private String description;
+
/
/// Accessors ///
/
@@ -85,7 +91,7 @@ public long getEntityOwnerId() {
@Override
public void execute() throws ResourceUnavailableException {
-NetworkACL acl = _networkACLService.updateNetworkACL(id,
this.getCustomId(), getDisplay());
+NetworkACL acl = _networkACLService.updateNetworkACL(this);
NetworkACLResponse aclResponse =
_responseGenerator.createNetworkACLResponse(acl);
setResponseObject(aclResponse);
aclResponse.setResponseName(getCommandName());
@@ -97,4 +103,12 @@ public void checkUuid() {
_uuid
[jira] [Commented] (CLOUDSTACK-10301) Allow updating the network ACL list name and Description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16432122#comment-16432122 ] ASF subversion and git services commented on CLOUDSTACK-10301: -- Commit b08f9e053ff301d59dc81283704be37dc1871905 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b08f9e0 ] [CLOUDSTACK-10301] Allow updating the network ACL list name and Description (#2462) * [CLOUDSTACK-10301] Allow updating the network ACL list name and description * Fixes suggested by Daan > Allow updating the network ACL list name and Description > - > > Key: CLOUDSTACK-10301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10301 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Currently, it is not possible to update the Network ACL name or Description > of an ACL after it has been created. It might be interesting to expose this > option via API and to add this feature to the UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10304) SystemVM - Apache Web Server Version Number Information Disclosure
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Gilbert updated CLOUDSTACK-10304:
Summary: SystemVM - Apache Web Server Version Number Information Disclosure
(was: Apache Server Version Number Information Disclosure from System VM)
> SystemVM - Apache Web Server Version Number Information Disclosure
> --
>
> Key: CLOUDSTACK-10304
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10304
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.11.0.0
>Reporter: Julian Gilbert
>Priority: Major
>
> {color:#00}The Secondary Storage System VM discloses its Apache Web
> Server version number in HTTP headers and error pages. This type of
> information disclosure can lead to medium vulnerabilities being reported in
> web vulnerability scanners and reveals the Apache server version
> unnecessarily.{color}
> {color:#00}The apache2 directory structure no longer contains
> /etc/apache2/conf.d/ in Debian 9 and therefore the appropriate apache2
> security configuration file is in another location. The
> /opt/cloud/bin/setup/common.sh script has not been updated to reflect
> this.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10304) Apache Server Version Number Information Disclosure from System VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Gilbert updated CLOUDSTACK-10304:
Description:
{color:#00}The Secondary Storage System VM discloses its Apache Web Server
version number in HTTP headers and error pages. This type of information
disclosure can lead to medium vulnerabilities being reported in web
vulnerability scanners and reveals the Apache server version
unnecessarily.{color}
{color:#00}The apache2 directory structure no longer contains
/etc/apache2/conf.d/ in Debian 9 and therefore the appropriate apache2 security
configuration file is in another location. The /opt/cloud/bin/setup/common.sh
script has not been updated to reflect this.{color}
was:
{color:#00}The Secondary Storage System VM discloses its Apache Server
version number in HTTP headers and error pages. This type of information
disclosure can lead to medium vulnerabilities being reported in web
vulnerability scanners and reveals the Apache server version
unnecessarily.{color}
{color:#00}The apache2 directory structure no longer contains
/etc/apache2/conf.d/ in Debian 9 and therefore the appropriate apache2 security
configuration file is in another location. The /opt/cloud/bin/setup/common.sh
script has not been updated to reflect this.{color}
> Apache Server Version Number Information Disclosure from System VM
> --
>
> Key: CLOUDSTACK-10304
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10304
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.11.0.0
>Reporter: Julian Gilbert
>Priority: Major
>
> {color:#00}The Secondary Storage System VM discloses its Apache Web
> Server version number in HTTP headers and error pages. This type of
> information disclosure can lead to medium vulnerabilities being reported in
> web vulnerability scanners and reveals the Apache server version
> unnecessarily.{color}
> {color:#00}The apache2 directory structure no longer contains
> /etc/apache2/conf.d/ in Debian 9 and therefore the appropriate apache2
> security configuration file is in another location. The
> /opt/cloud/bin/setup/common.sh script has not been updated to reflect
> this.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10355) After upgrade to 4.11, Ceph RBD primary storage fails connection and renders node unusable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431909#comment-16431909 ] Rohit Yadav commented on CLOUDSTACK-10355: -- [~exion] please use **Github issues for logging ticket: github.com/apache/cloudstack/issues. Use of Jira is discouraged. > After upgrade to 4.11, Ceph RBD primary storage fails connection and renders > node unusable > -- > > Key: CLOUDSTACK-10355 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10355 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent >Affects Versions: 4.11.0.0 >Reporter: exion >Priority: Blocker > > On a perfectly working 4.10 node with KVM hypervisor and Ceph RBD primary > storage, after upgrading to 4.11, cloudstack agent is unable to connect the > BRD pool in libvirt, giving just a generic "operation not supported" error in > its logs: > > 2018-04-06 16:27:37,650 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:91b4e1df) Attempting to create storage > pool be80af6a-7201-3410-8da4-9b3b58c4954f (RBD) in libvirt > 2018-04-06 16:27:37,652 WARN [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:91b4e1df) Storage pool > be80af6a-7201-3410-8da4-9b3b58c4954f was not found running in libvirt. Need > to create it. > 2018-04-06 16:27:37,653 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:91b4e1df) Didn't find an existing > storage pool be80af6a-7201-3410-8da4-9b3b58c4954f by UUID, checking for pools > with duplicate paths > 2018-04-06 16:27:37,664 ERROR [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:91b4e1df) Failed to create RBD storage > pool: org.libvirt.LibvirtException: failed to connect to the RADOS monitor > on: storagepool1:6789,: Operation not supported > 2018-04-06 16:27:42,762 INFO [cloud.agent.Agent] (Agent-Handler-4:null) > (logid:) Lost connection to the server. Dealing with the remaining commands... > > Exactly the same pool was previously working before upgrade: > > 2018-04-06 12:53:52,847 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-3:null) (logid:14dace5e) Attempting to create storage > pool be80af6a-7201-3410-8da4-9b3b58c4954f (RBD) in libvirt > 2018-04-06 12:53:52,850 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-3:null) (logid:14dace5e) Found existing defined storage > pool be80af6a-7201-3410-8da4-9b3b58c4954f, using it. > 2018-04-06 12:53:52,850 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-3:null) (logid:14dace5e) Trying to fetch storage pool > be80af6a-7201-3410-8da4-9b3b58c4954f from libvirt > 2018-04-06 12:53:53,171 INFO [cloud.agent.Agent] > (agentRequest-Handler-2:null) (logid:14dace5e) Proccess agent ready command, > agent id = 46 > > To workaround the issue I have tried to use the following XML config (dumped > from another node where it is correctly running) and define the pool directly > in libvirt, and it worked as expected: > > > be80af6a-7201-3410-8da4-9b3b58c4954f > be80af6a-7201-3410-8da4-9b3b58c4954f > > cephstor1 > > > > > > > > virsh pool-define test.xml > Pool be80af6a-7201-3410-8da4-9b3b58c4954f defined from test.xml > > root@compute6:~# virsh pool-start be80af6a-7201-3410-8da4-9b3b58c4954f > Pool be80af6a-7201-3410-8da4-9b3b58c4954f started > > root@compute6:~# virsh pool-info be80af6a-7201-3410-8da4-9b3b58c4954f > Name: be80af6a-7201-3410-8da4-9b3b58c4954f > UUID: be80af6a-7201-3410-8da4-9b3b58c4954f > State: running > Persistent: yes > Autostart: no > Capacity: 10.05 TiB > Allocation: 2.22 TiB > Available: 2.71 TiB > > And now the cloudstack agent correctly starts: > > 2018-04-09 10:29:19,989 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:f0021131) Attempting to create storage > pool be80af6a-7201-3410-8da4-9b3b58c4954f (RBD) in libvirt > 2018-04-09 10:29:19,990 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:f0021131) Found existing defined storage > pool be80af6a-7201-3410-8da4-9b3b58c4954f, using it. > 2018-04-09 10:29:19,991 INFO [kvm.storage.LibvirtStorageAdaptor] > (agentRequest-Handler-2:null) (logid:f0021131) Trying to fetch storage pool > be80af6a-7201-3410-8da4-9b3b58c4954f from libvirt > 2018-04-09 10:29:20,372 INFO [cloud.agent.Agent] > (agentRequest-Handler-2:null) (logid:f0021131) Proccess agent ready command, > agent id = 56 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431874#comment-16431874 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - blueorangutan commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-380007025 @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10230) User is able to change to “Guest OS type” that has been removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431870#comment-16431870 ] ASF GitHub Bot commented on CLOUDSTACK-10230: - borisstoyanov commented on issue #2404: [CLOUDSTACK-10230] User should not be able to use removed “Guest OS type” URL: https://github.com/apache/cloudstack/pull/2404#issuecomment-380006706 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User is able to change to “Guest OS type” that has been removed > > > Key: CLOUDSTACK-10230 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10230 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Critical > > Users are able to change the OS type of VMs to “Guest OS type” that has been > removed. This becomes a security issue when we try to force users to use HVM > VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable > by any users in the cloud. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
