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
