Il 10/07/2012 07:57, Hannes Reinecke ha scritto:
>> > This will make migration impossible not to mention the fact that
>> > casting a pointer to a uint64_t is really broken.
>> >
> Hey, this is _NOT_ an address. It's a simple way of generating a
> system-wide unique SAS address.
>
> The whole thing is informational anyway, and can only be seen when
> using the (proprietary) MegaCLI userspace command.
So even on real hardware it is not exported to the VPD (in the case of
the per-LUN address)? And the per-port address is also not visible in VPD?
I recently added a wwn property to scsi-{hd,cd}, a similar property
should perhaps be added to the megasas device. We can do the same thing
and add a default. Not the pointer value, though, because it is not
migratable. A counter is also problematic for migration when you have
hotplug/hotunplug. You can instead use something like a CRC32 of the
device id.
Once it's added, we can add support for it in SCSIBusInfo so that it is
exported via VPD.
> Okay, so here's the challenge: We need to generate a system-wide
> unique SAS address, one per SCSI device and one per megasas instance.
> A simple counter won't work, as we might have several qemu instances
> running. Which would result in all of them having the same SAS
> address for the host.
That's not a problem as long as we're not supporting things like
persistent reservations across guests (just like it's not a problem if
you give the same MAC address to network cards with slirp).
Paolo
