Hi All

I have problem with ESXi 4.1 on my two servers:
Server1: R710 Raid1 - 2x 146GB SAS and
Server2: Supermicro X8DTT without RAID one disk SATA 256 GB
Servers has been off for a week.
When I ran, I saw a message:
"Two Filesystems with the same UUID have been detected. Make sure you do not have two ESXi installations"

How do I fix this?
and did not restore the configuration?

Please Help
Tom

Are you getting the same error on both? What else to the hosts connect to for storage?

yes server have connection to storage.
I solve this problem I have shared storage connected to servers and LUN have ESXi installation.

Servers connected via iSCSI see ESXi partition on LUN and this partition have this same UUID, I delete virtual disc from matrix and all works

Thanks

I'm having this error message appear but it's probably because I'm approaching my copy incorrectly.

I've two 400gig HDD's - older PATA ones - I have a full 4.1 installation on my old one but the drive is starting to make noises when it's on its side and as it's western digital I don't trust it and I want to migrate the VM's to a Samsung of the same size.

I set up the Samsung with a basic 4.1 installation (by itself) and tried putting the WD along side so I could copy the datastore's contents over; problem is it's showing the same UUID.

Is it possible to modify the UUID to make it slightly different at all? Or is there a better way to copy my VM's across?

What do you get for ls /dev/disks/?

Thanks Dave, appreciate your help.

My objective is to mount the old datastore to transfer the VM's internally over to a newly built host on the new drive. I'm going to try another approach, I have a 3rd drive with an esxi 3.5 build to see if I can use that to mount the other data stores; I don't know how else I'd move these as the datastore partition seems to be unrecognised by most of the other distros I try to inspect it with.

As for these disks I put each disk in one at a time to get these readings:

old system:

~ # ls /dev/disks
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:1
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:2
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:3
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:4
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:5
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:6
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:7
t10.ATA_____WDC_WD10EACS2D00D6B0__________________________WD2DWCAU41660144:8
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:1
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:2
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:3
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:4
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:5
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:6
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:7
t10.ATA_____WDC_WD4000AAKB2D22UKA0________________________WD2DWCAPW2974248:8
vml.0100000000202020202057442d574341505732393734323438574443205744
vml.0100000000202020202057442d574341505732393734323438574443205744:1
vml.0100000000202020202057442d574341505732393734323438574443205744:2
vml.0100000000202020202057442d574341505732393734323438574443205744:3
vml.0100000000202020202057442d574341505732393734323438574443205744:4
vml.0100000000202020202057442d574341505732393734323438574443205744:5
vml.0100000000202020202057442d574341505732393734323438574443205744:6
vml.0100000000202020202057442d574341505732393734323438574443205744:7
vml.0100000000202020202057442d574341505732393734323438574443205744:8
vml.0100000000202020202057442d574341553431363630313434574443205744
vml.0100000000202020202057442d574341553431363630313434574443205744:1
vml.0100000000202020202057442d574341553431363630313434574443205744:2
vml.0100000000202020202057442d574341553431363630313434574443205744:3
vml.0100000000202020202057442d574341553431363630313434574443205744:4
vml.0100000000202020202057442d574341553431363630313434574443205744:5
vml.0100000000202020202057442d574341553431363630313434574443205744:6
vml.0100000000202020202057442d574341553431363630313434574443205744:7
vml.0100000000202020202057442d574341553431363630313434574443205744:8



New system:


~ # ls /dev/disks
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:1
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:2
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:3
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:4
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:5
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:6
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:7
t10.ATA_____SAMSUNG_HD400LD_________________________S0AXJ1LLB33914______:8
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:1
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:2
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:3
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:4
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:5
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:6
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:7
vml.0100000000533041584a314c4c42333339313420202020202053414d53554e:8


Thanks!


DT

I've inspected the partitions with a GNOME partition manager to get the UUID's - the system's giving the same UUID to the Hypervisor partitions (all four) on both drives. I'm presuming it's doing this either by generating the same numbers during installation or it's using a set group are pre-defined for the FAT16 partitions.

I'm thinking that if I change the UUIDs for the 2nd one temporarily and then try a boot it may bypass the problem - I want to be able to change it back as a reversion strategy.

Not entirely sure how to do this safely - or it it'll do what I'm expecting it to do, any ideas of what could work? I'm not looking for long term, just enough to copy the VM's from one datastore to the other.

I'm just trying some stuff in the lab. So far deleting partitions hasn't helped, but I'm looking next into changing the UUID.

Aaah cool thanks Dave - I actually considered doing that but I wanted to hang on to the reversion strategy... I'm not sure if installing ESXi4 to another sized drive will generate different UUIDs, I've actually run out of hard drives to try it on as I'm retaining the original Jan-2011 patched build to test out a Realtek NIC driver when it becomes available.

It's an interesting problem, I wonder if this has been seen in earlier versions? Or if it's possible to turn off the integrity check in boot?

I've tried changing the volume IDs on the partitions (hypervisor 0 > 3) on the 2nd (source) disk and that hasn't done it. Also changed the disk ID and still am getting the same error.

There's an open source VMFS driver out there. You would boot with a live CD, run the driver - http://code.google.com/p/vmfs/ and then copy between the two.