On Thu, Oct 29, 2026 at 02:16:38PM +0100, Kevin Wolf wrote:
Am 29.10.2026 um 13:51 hat Stefan Hajnoczi geschrieben:
On Thu, Oct 29, 2026 at 12:23:59AM +0100, Kevin Wolf wrote:
If the guest can only see the first 20 characters of the serial, we shouldn't pretend to have a longer string in the 'serial' qdev property (which is visible through things like QOM or 'info qtree').
Truncate the serial already in the internal state of the device to make sure we don't mix both versions anywhere.
This is a user-visible change that can break software relying on QEMU's serial string output. For example, imagine QEMU is launched with a serial string that is the UUID 22382676-e635-4dca-a1db-0eaf2e2e192a. Later on, a script fetches the serial from QEMU monitor output and uses it as the volume identifier in a distributed storage system (e.g. to fetch volume statistics for the guest's disk). That script will now break because QEMU no longer retains the full string.
Do we know of any such management tools, or is the concern just out of an abundance of caution?
It sounds fundamentally wrong to me to use the serial as opposed to the qdev id to identify devices.
Based on qemu-devel threads (e.g. tracking IOThread holders) it seems that people write management tools that query QEMU rather than maintaining their own state. While I don't know of a specific tool that uses the serial string, it doesn't seem far-fetched that someone might rely on this. I don't think we gain enough from changing the monitor output that it's worth risking breaking existing users.
Let's hold off on this change until the deprecation grace period finishes.
I can drop the patch for a v2 of this series (or just apply it without this patch if no other changes are necessary) as the value of the qdev property should be the only real effect at the moment.
However, with the work that actually enables longer serials, having an internal state that doesn't match what the guest sees feels rather error prone. So I'd be happy to defer the change of the serial in the internal state to the 12.0 cycle, but probably not until after the deprecation period.
I would still hold off until it is actually time to enforce the length limit according to the deprecation policy, but I guess there's an argument that once users can configure long strings, they should stop abusing the serial property. In any case, lets defer this patch for 11.2. Stefan