cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Tutkowski (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-6514) VMware: Is space allocated for snapshots counted correctly?
Date Thu, 13 Nov 2014 15:46:33 GMT


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

What do you think?


> VMware: Is space allocated for snapshots counted correctly?
> -----------------------------------------------------------
>                 Key: CLOUDSTACK-6514
>                 URL:
>             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
> 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

View raw message