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

[silicon]

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.

[silicon]

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.

[Robotbeat]

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.

[silicon]

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

[Robotbeat]

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

...
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?

[silicon]

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!

[silicon]

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.