The API for the free Hypervisor is also limited to mostly read commands. Since PowerCLI - like other tools - uses the API it is restricted too.
André
The API for the free Hypervisor is also limited to mostly read commands. Since PowerCLI - like other tools - uses the API it is restricted too.
André
Hi,
If I create a datastore of 2TB and create a VM with a thin provisioned disk of 1.5TB, then lets say I create a snapshot and leave the VM running on the snapshot for a while.
Will the VM space consumption (now including the snapshot) still be restricted to 1.5TB? Meaning the datastore can never run out of space in this scenario with a VM on a snapshot?
I know that keeping the snapshot for more than 72 hours is not recommended but want to understand what is the space limit of a snapshot (VM vdisk vs VMFS datastore)
Thanks
I have the same problem (with a slightly different offset than yours).
After testing a little bit I think I have an idea what the source of the problem
may be: The MacOS scaling setting for the display.
When I set the MacOS display resolution to standard (the native resolution of
the display, in my case 3820x2160),I do not notice any offset for the mouse
pointer, e.g. trying to resize a window changes the cursor shape exactly at
the expected position.
When I change the MacOS display resolution back to my preferred scaled
setting of 3008x1692, i observe the pointer offset you describe. For example
the cursor shape for resizing a window does not change at the expected
position but quite some pixels to the left (for changing the width of the window
at the left or right side).
Until now I found no solution to this problem (other than disable the
scaling). I assume it is a bug in the position tracking/aligment of the
mouse pointer inside VMware Fusion.
Will the VM space consumption (now including the snapshot) still be restricted to 1.5TB? Meaning the datastore can never run out of space in this scenario with a VM on a snapshot?
No, each snapshot can grow up to its base virtual disk's provisioned size (plus some overhead).
Also keep in mind that once the snapshot grows to a certain size, you may not be able to consolidate/delete it anymore, depending on the changes, and the size of the base disk.
André
I never tried this myself, so my answer is based on the documentation.
André
But I think it not works correctly ...
As mentioned by the other user before, you don't need to worry. The behavior is by design.
André
Thanks. I can't see HA with pacemaker in Vmware Learning Platform.
There is possibility to make that with openfiler?
thanks!
Personally I will not go with Windows 2016 and above.
If you have not seen this link, it is worth
https://www.altaro.com/vmware/how-to-setup-vsan-using-a-nested-environment/
Ok so the risks (in terms of disk space) in this case scenario (assuming 1 VM on this datastore) is that the VM base disk will run out of free disk space.
Also as far as I understand you cannot resize the base disk if there is a snapshot applied.
So one would want to avoid the situation in which the snapshot grows too much that it requires more free space to be consolidated/deleted but at the same time time you cannot expand the VM base disk because there is a snapshot. So basically you and end up with a chicken and egg scenario.
Sorry but Iṁ trying to understand your question.
My question: what should be my main goal be when choosing the capacity drives for a disk group?
Goal or design criteria is always around sizing.
what your performance requirement is, keep 10% minimum for cache and remaining 90% capacity drive.
Does that help?
Also, is there a reason you do not wish to consolidate disk group.
> The closest workaround is to opt-click the green button, which will maximize the window without turning it into a space.
Didn't know that 'trick' which maximises the window to the screen. Alas it leaves the wasted menu bar space.
But a very useful point.
Ok so the risks (in terms of disk space) in this case scenario (assuming 1 VM on this datastore) is that the VM base disk will run out of free disk space.
Not the base disk, but the datastore may run out of disk space if a VM has active snapshots, or when you try to consolidate/delete snapshots with thin provisioned base disks.
Also as far as I understand you cannot resize the base disk if there is a snapshot applied.
Yes, that's corect. A snapshot .vmdk file contains metadata, based on the base disk's provisioned size at the time of the snapshot creation.
So one would want to avoid the situation in which the snapshot grows too much that it requires more free space to be consolidated/deleted but at the same time time you cannot expand the VM base disk because there is a snapshot. So basically you and end up with a chicken and egg scenario.
You are mixing up two things, free space in the base disk, and free disk space on the datastore. Resizing a virtual disk may only be required, if the guest OS requires more space. Deleting a snapshot however is transparent to a guest OS, and is only about the growth of the base .vmdk file on the datastore.
Example: If the thin provisioned base .vmdk file - at the time you create a snapshot - has a size of let's say 500GB, and you let the snapshot grow to ~1TB (assuming its additional data), then the .vmdk files will consume 1.5TB on the datasatore. Consolidating/deleting the snapshot at this point will not work anymore, because the data from the snapshot .vmdk file needs to be merged into the base .vmdk file (expanding t to 1.5TB) before the snapshot files can be deleted from the datastore. In this example the required disk space on the datastore would be ~2.5TB, which exceeds the 2TB datatore size. 1.5 TB for the base .vmdk file, and 1TB for the snapshot .vmdk file.
André
In addition to the replies above, not sure where the 72 hours thing comes from - never keep snapshots for any longer than necessary (ie. during backups, app/OS updates, and very little else!)
Thanks. I can't see HA with pacemaker in Vmware Learning Platform.
To be able to give you an advice, it is necessary that you explain what exactly you are trying to set up/achieve.
André
Ok so snapshot deletion will consume space from the datastore and nothing to do with the free space left in the base disk.
I think the above was not clear to me as I thought that once you provision a VM with a vdisk of a certain amount (what ever disk format) - no activities (temporary or not) would be able to consume more than that on the datastore.
If the above is correct that proves to be wrong and snapshot deletion is one example.
thanks, yes I know that but the focus of this thread is to understand the snapshot disk space inner workings/utilisation/limits
Thanks for the options. I'll give them a try and report my results.
André:
Thank you for your help! I used the function of Upload Folders, but it stopped at 15%,Is it possible to analyze the problem from where the logs are? Thank you!
I think the above was not clear to me as I thought that once you provision a VM with a vdisk of a certain amount (what ever disk format) - no activities (temporary or not) would be able to consume more than that on the datastore.
That's unfortunately not the case. As mentioned, each snapshot may grow up to the virtual disk's provisioned size, which can already cause issues, and using thin provisioning for virtual disks is one more reason, why it's important to monitor disk space usage on a datastore.
André
I'm currently not sure which log file to look at for such issues.
Anyway, can you please clarify how exactly you are doing the upload, What confuses me is the "I used the function of Upload Folders" you mentioned. Maybe some screenshots will help.
André