Who is feeling the pain for shrinking VM’s?
From informal surveys conducted with ex-colleagues and developers in other companies, and the inquiries we are receiving, the picture that has emerged in my mind is that shrinking VM’s is a need for
- Developers who can store a limited number of VMs on their personal workstations/laptops.
- Developers and particularly System Administrators who are concerned about the performance of their app within the VM at run time
- Release Engineers/System Administratrators who have to transfer VM images from a staging/build/test machine to one or more production servers in a remote data center, or in the cloud, and are interested in reducing their size, and hence the elapsed time for the file transfer .
Release Engineers/System Administrators dealing with production VMWare ESX deployments seem to be storing VM’s on storage that supports de-duplication, primarily from
Development teams in large companies do use NetApp filers to provide shared NFS-mounted storage for development teams. However, I am not sure whether these filers support de-duplication, and if they do, whether it is enabled. If de-duplication is indeed enabled, then these shared filesystems typically act as passive storage for VM’s created by developers/build masters and the overall demand for storage reduces considerably.
However, there are development teams that also use commodity storage for file shares. If they are Linux file shares, then the ext3 file system seems to be the industry-standard; otherwise, they are Windows NTFS file shares. Both these file systems are also found on developer desktops – they don’t support de-duplication and have the exact same defragmentation and VM shrinking challenges that the developer faces on his personal workstation – except that the pain for managing file shares is felt by the IT admin/operator responsible for its well being. (It is worth reading this informative article about dealing with VM snapshots and linnked clones on Windows NTFS).
The major pain for managing several VM’s stored on commodity storage on a workstation/laptop seems to be felt by the developer since he can only offload older VM’s on a USB drive or a shared filesystem for “archival”, and has to keep the current one’s that he is testing on the local disk. We are hoping this blog is providing pointers to the “how to” for the developers, release engineers and system adminsitrators.