Description of problem: I'm not sure if downstream QEMU, without mentioning a serial ID for disk, sets a persistent one. Some programs use it (example: one of the Windows activation checks is if a disk was changed - and this is done by checking its ID. Another example - I suspect it's required for WHQL signing of block drivers). We should add,serial=ca-b642-ebc2348af830 (for example) to the -drive parameter of QEMU Version-Release number of selected component (if applicable): Essex How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Disks that are attached backed by Cinder volumes do get a 'serial' property set, but the regular OS disks do not. Should be pretty trivial to address this.
@danpb: can you confirm that this is still the case? From what I can tell, on the latest version of the nova code, it would appear that everything gets assigned a serial property (there seem to be several explicit checks which say that if 'serial' is not in the connection info, use the volume id as the serial). Is this still incorrect behavior?
It is still broken. Only the disks which are based on cinder volumes have a serial attribute set. Nothing in imagebackend.py is ever setting a serial attribute. Even the cinder based serial attribute is really broken, because it is used a UUID string which gets truncated by QEMU, since the max serial field length is shorter than a UUID string. We really need to re-think what we use for serial attributes with cinder volumes, and also make non-volume based disks have a serial attribute. A consistent naming scheme across both would be desirable
This item has had a change in release flag, and has been removed from tracking in OSP14.GA
Spec resubmitted: https://review.openstack.org/595247
This has been open for a long time and we've made a couple of attempts at resolving this upstream. There's no longer a strong customer request attached to this so I'm going to close this. We can open a new RFE if this becomes a priority again in the future.