cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
Date Thu, 01 Feb 2018 13:06:00 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348545#comment-16348545
] 

ASF GitHub Bot commented on CLOUDSTACK-9338:
--------------------------------------------

rafaelweingartner opened a new pull request #2443:  [CLOUDSTACK-9338] ACS not accounting resources
of VMs with custom service offering properly
URL: https://github.com/apache/cloudstack/pull/2443
 
 
   ## Description
   ACS accounts the resources when deploying VMs with custom service offerings. However, there
are other methods (such as updateResourceCount) that do not execute the resource accounting
properly, and these methods update the resource count for an account in the database. Therefore,
if a user deploys VMs with custom service offerings, and later this user calls the “updateResourceCount”
method, it (the method) will only account for VMs with normal service offerings, and update
this as the number of resources used by the account. This will result in a smaller number
of resources to be accounted for the given account than the real used value. The problem becomes
worse because if the user starts to delete these VMs, it is possible to reach negative values
of resources allocated (breaking all of the resource limiting for accounts). This is a very
serious attack vector for public cloud providers!
   
   ## Steps to reproduce:
   
   1. Create a new account and dedicate some resources to it
   2. Instantiate a VM using a custom service offering
   3. Check the CPU and memory resource count for the given VM (the count must be correct
at this point): select * from resource_count where account_id = ?
   4. Go to the details of the account and click on “Update resource count”
   5. Execute the SQL again (select * from resource_count where account_id = ?), and check
if the resource count is correct. The value of resource count will consider only VMs deployed
with normal service offering;
   6. Delete all VMs
   7. Check the resource count table again. It will reach negative values.

----------------------------------------------------------------
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:
users@infra.apache.org


> updateResourceCount not accounting resources of VMs with custom service offering
> --------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9338
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API, Cloudmonkey, UI
>    Affects Versions: 4.5.2, 4.8.0
>         Environment: CloudStack 4.5.1
> MariaDB 10.0 and 10.1
>            Reporter: Francois Scheurer
>            Assignee: Rafael Weingärtner
>            Priority: Major
>
> listAccount on a domain returns 0 for cputotal and memorytotal if the domain accounts
own VMs using a ComputeOffering with custom=enabled.
> Basically, looking into the vm_instance table you get the service_offering_id and in
the service_offering table you find normally the amount of CPU/RAM allocated for the VM.
> But if your VM's ComputeOffering has custom=enabled, then you need to get the specific
CPU/RAM values from the user_vm_details table:
> mysql> select * from user_vm_details WHERE vm_id=957;
> Apparently the listAccount code is not doing that and it just returns zero, because the
service_offering table has cpu=0 and ram_size=0 for ComputeOfferings with custom=enabled.
> solution: the SQL query of listAccount should also look in the user_vm_details table
for matching rows. (instead of just querying in the service_offering table)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message