1

I have a LUN in our VMware 6.7.0 world. For a specific project we need to safe-delete (with a standard method like DoD 5220) the data on this LUN with some kind of deletion protocol. The underlying storage system is a 3PAR SSMC with VMFS 5 and the SCSI Controller is VMware Paravirtual. The LUN is used by ~15 VMs (which are all marked for deletion) as storage with Tick-Provision Lazy-Zeroed.

After a while searching the web I only found the paid solution "Blancco LUN Eraser". However, we have to delete it today. Is there any other way to secure-delete with a protocol?

My first idea was to just use DBAN on each individual VM and delete every individual "Disk". After that just deleting the LUN in vSphere. This was discussed at VMWare too: https://communities.vmware.com/message/989618#989618

Any ideas? I'm running out of possibilities and ideas myself.

Stuggi
  • 3,366
  • 4
  • 17
  • 34
moTHO.
  • 23
  • 5
  • Just the basics would help - how's the LUN presented, what version of ESXi/vCenter, is this a VMFS datastore or a LUN presented straight through to one or more VMs such a the use of RDMs or iSCSI into the guest OS, if it's a DS is it being used to present primary or secondary VMDKs, why are you struggling to do this and looking at third party solutions, just more detail, more explanation. Look at other questions on this site, people come prepared, they provide the problem in detail that gives us a chance to come up with a solution, I know you're new to the site but we have extensive help pages – Chopper3 Oct 15 '20 at 10:52
  • It's not like I don't try to provide more information to get a helpful answer. I'm pretty new to this whole topic and I edited the question a dozen times to fill it with informations. I naturally had a look in the VMware docs but couldn't find any solution for this. @Chopper3 I looked for third party tools as I couldn't find an option other than just deleting the LUN which would release the storage used but the 16KB chunks will remain with data and could possibly be restored. It has to be completely wiped. – moTHO. Oct 15 '20 at 11:04
  • 1
    what's wrong with just 'DD'ing over the LUN with /dev/random? – Chopper3 Oct 15 '20 at 11:27
  • Maybe this would fit but I really have no clue as I don't know how to access the LUN. The previous administrator changed the password of the 3PAR interface so I can't access it through this. – moTHO. Oct 15 '20 at 12:51
  • 2
    The first thing you need to do is to regain access to the storage server. Then find out if it has encryption-at-rest enabled. If so, you can just delete the LUN and that is the end of it. The encryption key is gone and the data is unrecoverable. If encryption-at-rest is not enabled, you're going to have a really bad time. AFAIK without it your only option is to erase ALL the disks. But maybe someone else will have another idea. – Michael Hampton Oct 15 '20 at 14:39

1 Answers1

4

What you essentially want to do is to wipe the whole datastore, as DBAN-ing the individual VMs doesn't guarantee that every single bit of the underlying LUN gets overwritten.

As long as the underlying storage for the datastore is presented over iSCSI or FC to the ESXi, it should show similarly as Direct Attached Storage, and then you should be able to overwrite it with dd from the ESXi console. See this site for more context.

For example:

# dd if=/dev/zero of=/dev/disks/t10.NVMe_Samsung_SSD_960_EVO conv=notrunc

However, as Michal Hampton pointed out, it's best to investigate the options on the underlying storage first. HPE Proliant Servers has had this feature since Gen8 (so around 2014 maybe), so I'd be quite surprised if 3PAR doesn't as well.

As a point of interest as well, VMFS5 doesn't support UNMAP either, so any deletion in VMware doesn't result in blocks being marked as free on the underlying storage. VMFS6 however changes this to support asynchronous space reclamation (basically ESXi scans through the datastores in its spare time and sends SCSI UNMAP commands to the storage so that it knows what blocks it can repurpose). In this case it's rather important depending on what you're trying to achieve, and how the underlying storage operates.

Stuggi
  • 3,366
  • 4
  • 17
  • 34