[
https://issues.apache.org/jira/browse/CLOUDSTACK-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209923#comment-14209923
]
Mike Tutkowski commented on CLOUDSTACK-6514:
--------------------------------------------
So, let's see...that's a good question.
I guess it depends exactly on the nature of the problem we're aiming to solve
here.
If we are just looking to see how much space is currently allocated from a
given datastore, then we just need to make sure we're not double/triple/etc.
counting the shared template.
I'm not sure, however, if the current database structure if flexible enough to
accommodate this technicality. As it stands now, I think the DB wants a size
for the volume and then a size for its snapshots, if any. This makes it
difficult to account for a shared template.
If we simply want to know how much space is available in the given datastore,
would it be simpler to query vSphere for this info as needed? I know it's
faster if we have the data already available in the DB, but that approach might
require some scheme updates to store this info differently.
What do you think?
Thanks!
> VMware: Is space allocated for snapshots counted correctly?
> -----------------------------------------------------------
>
> Key: CLOUDSTACK-6514
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6514
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
> Affects Versions: 4.4.0
> Environment: Ubuntu 12.04 for CloudStack Management Server (just one
> in this config)
> Two ESXi 5.1 hosts
> Reporter: Mike Tutkowski
> Assignee: Mike Tutkowski
> Fix For: 4.4.0, 4.5.0
>
>
> long CapacityManager.getAllocatedPoolCapacity(StoragePoolVO, VMTemplateVO)
> may not add up allocated space in the passed-in storage pool properly for
> VMware.
> The idea is to count the allocated space of all non-destroyed volumes and the
> corresponding allocated space of their snapshots, if any. In addition,
> templates on the storage pool should be taken into consideration.
> I think the number that is in the vm_snapshot_chain_size column of the
> volumes table is not correctly calculated (and this number is used by the
> getAllocatedPoolCapacity method when it invokes another method).
> This is how it currently works when you have a new VM and you take a snapshot
> of it for the first time (not taking a snapshot of memory):
> These are the relevant files and their respective sizes:
> ROOT-21-000001-delta.vmdk (16,785,408 bytes)
> ROOT-21-000001.vmdk (316 bytes)
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> We include these files for the vm_snapshot_chain_size:
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> I think we should be counting these instead:
> ROOT-21-000001-delta.vmdk (16,785,408 bytes)
> ROOT-21-000001.vmdk (316 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> My thinking is that when we add up the total space that this volume consumes
> that we've already taking into account 2,147,483,648 bytes because this value
> is stored in the size column of the volumes table.
> I would think we'd want to add up the sizes of the VMSN files and the sizes
> of the -xxxxxx files to arrive at vm_snapshot_chain_size?
> Any thoughts on this?
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
