jackym
Contributor
Contributor

is it possible to delete vmdk files

Hey guys,

Am new to vmware , in our virtualized work environment, we have two 2 datastores raid1 and raid 10 that are hosting the vm and apparently raid 10 storage is almost filling up. when we browse through the datastore we are seeing .vmdk files that span from 2018 as the date modified. Now my question is will it be possible to delete the old vmdk files without interfering with the virtual machine? or how should I go about it to free up some space for the vm to continue working well?

TIA

Jackyne

Labels (1)
  • VM

Tags (2)
0 Kudos
9 Replies
depping
Leadership
Leadership

Sure, if the disks are not used you can delete them, but it would not be normal to have disks which are unused. I would probably use a script to produce a report, and based on that report take action: https://communities.vmware.com/t5/VMware-PowerCLI-Discussions/How-to-find-Orphaned-VMDK-files/td-p/1...

0 Kudos
a_p_
Leadership
Leadership

>>> ... we are seeing .vmdk files that span from 2018 as the date modified. 
One possible reason is that your VMs do have active snapshots, where only the latest .vmdk file in the snapshot chain will be modified, but all other .vmdk files in the snapshot chain are also required.

An alternative to the provided script is RVTools, which - in addition to many other things - can detect "Zombie" files.

In doubt, do NOT delete files directly from the datastore, but provide some details (e.g. a complete file listing), so that we can take a look at them.

André

jackym
Contributor
Contributor

Thanks for your reply guys, i tried to log in to the vmware web client and browsed to the affected data store the following is the listing of the Dmks files and their date of modification . also downloaded the RV Tool as you had suggested but from their when I check on the Vhealth am seeing consolidation is required message but no 'zombie' snapshots. THANKS

 

Name    Last modified     Size

________________________________________

Parent Directory                              -

SERVER_1-000001-delta.vmdk   10-Sep-2018 07:59           81370525696

SERVER_1-000001.vmdk               04-Sep-2018 03:51           327

SERVER_1-000002-delta.vmdk   13-Apr-2021 10:39            267647954944

SERVER_1-000002.vmdk               06-Apr-2021 06:00            361

SERVER_1-flat.vmdk       14-Jun-2018 12:39            536870912000

SERVER_1.vmdk               07-May-2018 06:00          529

SERVER_2-000001-delta.vmdk   10-Sep-2018 07:59           214379679744

SERVER_2-000001.vmdk               04-Sep-2018 03:51           326

SERVER_2-000002-delta.vmdk   12-Apr-2021 07:09            213507264512

SERVER_2-000002.vmdk               06-Apr-2021 06:00            360

SERVER_2-flat.vmdk       14-Jun-2018 12:39            214748364800

SERVER_2.vmdk               07-May-2018 06:00          528

________________________________________

0 Kudos
continuum
Immortal
Immortal

You need to learn how to follow a snapshot chain with WinSCP to avoid costly mistakes !!!

Get WinSCP !

Read current vmx-file of the VM.

It probably says it is currently using SERVER_1-000002.vmdk

Next read SERVER_1-000002.vmdk  - it probably says parentfile is SERVER_1-000001.vmdk

Next read SERVER_1-000001.vmdk - it probably says parentfile is SERVER_1.vmdk 

Now you just learned that none of the files:

SERVER_1-000001-delta.vmdk 10-Sep-2018 07:59 81370525696

SERVER_1-000001.vmdk 04-Sep-2018 03:51 327

SERVER_1-000002-delta.vmdk 13-Apr-2021 10:39 267647954944

SERVER_1-000002.vmdk 06-Apr-2021 06:00 361

SERVER_1-flat.vmdk 14-Jun-2018 12:39 536870912000

SERVER_1.vmdk 07-May-2018 06:00 529

is not part of the active chain ==== you cant delete any of those.

 

Practise this checks - it will safe you a lot of headaches in the future.

 

 

 

 

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"
0 Kudos
a_p_
Leadership
Leadership

That's what I thought. You have 3 years old active snapshots, which consume considerable disk space
Depending on the virtual disks' provisioning type (thin or thick), deleting the snapshots may require additional free disk space.

Please run ls -lisa as well as df -h in the VM's folder, and post the result. The first command will list all files with their provisioned sizes as well as the used disk space, and the second command will show the free disk space.
Just in case there's not enough free disk space on the VM's current datastore, let me know whether you have other datastore with sufficient free disk space that could be used to clone the VM.

André

0 Kudos
jackym
Contributor
Contributor

Hi guys I do appreciate your feedback. Currently this datastore doesn't have enough space it has like 4.5Gb. we used thin provisioning. We also have another datastore that has some good free space. If we were to do VM clone as you have suggested will it b possible to use the other datastore then after cleaning it we revert back?

Thanks in advance 

Jackie

 

 

0 Kudos
a_p_
Leadership
Leadership

Sure no issue with migrating virtual disks between datastores.
Cloning may require downtime, and some manual configuration. Whether downtime is required to migrate the virtual disks back to the current datastore depends on your vSphere edition.

André

0 Kudos
jackym
Contributor
Contributor

Thanks André for your feedback,

In the other datastore we have like 350gb free space ,will that be enough to enable us migrate given the size of the vmdk files we have or we need the exact space? We are also thinking of doing consolidation but not sure whether the current space we have of 4.5 GB will be enough to enable us perform consolidation. Also is it possible to add internal hard disk to raid 10? 

Thanks in advance

Jackie

0 Kudos
a_p_
Leadership
Leadership

I can't tell you what to expect without details. Please post the resolt of the  ls -lisa *.vmdk command, to see how much disk space the .vmdk files currently consume. According to what you've provided earlier the VM has two virtual disks (200GB + 500GB), why it's important to know about the currently consumed disk space.

André

0 Kudos