Repurposed disk - Linux blkid command returns incorrect information

I'm working with an SSD drive removed from a VMware ESXi installation. I'm trying to reuse the disk in an existing Linux installation (CentOS 6.2). The drive sits behind an HP Smart Array P410 RAID controller and is configured as a separate logical drive.

When I first attempted a format of the disk, I received the following:

[root@poot ~]# fdisk -l

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 240.0 GB, 240021504000 bytes
255 heads, 63 sectors/track, 29180 cylinders

I followed the instructions here to remove the GUID partition table using gdisk:

[root@poot ~]# gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.2   

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if
you don't want to convert your MBR partitions to GPT format!
***************************************************************


Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.

Command (? for help): x

Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): y
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Blank out MBR? (Y/N): y

I proceeded to fdisk, then mkfs.xfs an XFS filesystem on the drive. I usually mount using disk labels, but since EL6, have started to adopt UUID mounting. With this disk, however, mounting by label fails. I tried to retrieve the UUID, but the blkid command is returning bad or stale data with a UUID_SUB and TYPE="VMFS_volume_member".

[root@poot ~]# mkfs.xfs -f -L /data -d agcount=50 -l size=1024m,version=2 /dev/sdb1
meta-data=/dev/sdb1              isize=256    agcount=50, agsize=1171975 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=58598744, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal log           bsize=4096   blocks=262144, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

[root@poot ~]# mount /data/
mount: special device LABEL=/data does not exist

[root@poot ~]# blkid       
/dev/sda1: UUID="7406b992-4aab-4164-bfa1-1920f97658c7" TYPE="ext4" 
/dev/sda5: UUID="2390f2aa-d671-430d-b286-c6eca7c073a6" TYPE="swap" 
/dev/sda7: UUID="3c6f94d5-3898-4f36-be16-a33cf175d2ca" TYPE="xfs" 
/dev/sdb1: UUID_SUB="4eb0c035-4fe6b2d8-77ed-00265583f46d" UUID="4eb0c035-4b5714b0-b987-00265583f46d" TYPE="VMFS_volume_member" 

I've never seen anything like this before.

I've tried deleting /etc/blkid/blkid*. It seems to have persisted across reboots as well. What can I do to clear this data and obtain a clean UUID??

For this case you need to erase more than 1 MiB to kill the old VMFS superblock:

dd if=/dev/zero of=/dev/sdb1 bs=4M count=1

According to the blkid sources, the VMFS volume member superblock is located at the 1024 KiB offset from the start of partition, and the VMFS filesystem superblock is at the 2048 KiB offset, so erase 4 MiB just to be sure.

dd if=/dev/zero of=/dev/hdX bs=1M count=16 should clear the GPT and allow you to use fdisk or any other partition/slice system you want.

Warning: For others, if it isn't completely obvious, this will destroy whatever is currently on the disk.