XEN issue: UUID of vol changed with v5 to v6 upgrade

We just had a Citrix XEN issue that others may be able to comment on.
It seems (according to the Citrix engineer) the UUID of an iSCSI vol/LUN associated with a XEN Storage Repository changed when we did a DSS v5 to v6 upgrade, causing XEN to loose connection with the LVM data that was on that LUN. We may have then compounded the problem by detaching, then failing that, "forgetting" & recreating the SR definition, in an attempt to sort it. We thought also that IETD vs SCST may have been the issue, but we eliminated that. (another possible complicating factor may have been adding a v6 demo product key, which seems to scap the setup & config data, requiring it to be reloaded again.)

The the Citrix engineer was able to do his Linux magic & correct the LVM data for the SR, pointing it to the new UUID, and saved the day (well, late night/s actually!).

Anyway,
(a) should the UUIDs of volumes change across version upgrades?
(b) how does we make sure this doesn't happen again?
From the XEN docs, we should have been able to detach & re-attach the SR, even if we have moved the LUN to a different location.
(note that the UUID is different from the SCSI ID, which is associated with just the ISCS target. Both strings were in the /iscsi/target001.conf file in DSS, but I am not clear which are stored/preserved in the setup/config data file). Cheers.

Sorry, I forgot to add that 2 iSCSI vols/LUNs with Windows NTFS data on them were absolutely fine, the issue was restricted to the iSCSI vol/LUN associated with a XEN SR.

Any XEN experts out there?
I guess this does not apply to ESX, as no one seems to have mentioned any problems upgrading from v5 to v6. But I wonder how many people have done this yet? Cheers.

Is this the same as the SCSI id? Because you can manually change the SCSI id whenever you add a logical volume to a target. I do this when I set up autofailover (so that the dest. and source have the same scsi-id) so that the clients think that the primary and secondary targets are the same and don't get screwed up by a different scsi-id when failover happens.

If you can find out the old SCSI-ID, then just remove the logical volume from its target, then add it again, while changing the SCSI-ID to be the same as the old SCSI-ID.

Thanks for the suggestion re SCSI ID (& for autofailover config), but no, the Citrix engineer was only concerned with the UUID. I dont fully understand, but believe that is string is made available to an iSCSI initiator, but that most intiators ignore it. The XEN iSCSI initiator on the other hand, appears to have recorded as part of it's Storage Repository definition. DSS records this UUID in both the volume definition & the iSCSI target definition.

Eg. in this case:
UUID of volume: d64WTF-VB6E-yC3o-1x2o-2EM9-uc9b-EwHZOu
SCSI ID of LUN: VB6EyC3o1x2o2EM9

It looks to me that the UUID has the SCSI id embedded in it, according to your post:

Quote:

---

...
UUID of volume: d64WTF-VB6E-yC3o-1x2o-2EM9-uc9b-EwHZOu
SCSI ID of LUN: VB6EyC3o1x2o2EM9

---

(emphasis mine)
I wonder if changing the SCSI ID in the open-e gui will change the UUID to coincide?

Good point, maybe. It would take more testing to see what the relationship is between them & what's actually saved in the setup/configuration set. Might wait till the next XEN SAN upgrade to go through that!

Like an idiot I rushed thru this process again with ESX 3.5, swapping-out a DSS v5 DoM, thinking that the UUID issue would not arise (like it did with XEN). But I ended up having to use a v6 demo (the v5 would not run in 32-bit mode correctly), and I totally forgot about the IET->SCST issue. So had to go through the "resignaturing" process for storage definitions - it works, but less than ideal.

So a warning to everyone out there with XEN or ESX hosts - what may look like a simple change/update of DSS version, can bring lots of unexpected effects! Cheers.