On Thu, 2019-01-31 at 19:31 +0800, Zhenyu Zheng wrote:
Thanks alot for bring this up, if we decided to make unique serial the only choice, I guess we have to sort on what curcumstances it will
change the serial of instances that already exists. Should we have a way to preserve the serial for exisiting instances in order to not
cause any workload failue for our customers as changing the serial may cause some problem.

I think all that's necessary here is to add a reno calling out this change in behavior (along with the alternatives put forth by Sean and Matt) and, ideally, start setting 'chassis.serial' if libvirt > 4.1.0?

Stephen

On Sat, Jan 26, 2019 at 7:30 PM Stephen Finucane <sfinucan@redhat.com> wrote:
On Fri, 2019-01-25 at 18:52 -0600, Matt Riedemann wrote:
> On 1/25/2019 10:35 AM, Stephen Finucane wrote:
> > He noted that one would be a valid point in
> > claiming the host OS identity should have been reported in
> > 'chassis.serial' instead of 'system.serial' in the first place [1] but
> > changing it now is definitely not zero risk.
>
> If I'm reading those docs correctly, chassis.serial was new in libvirt
> 4.1.0 which is quite a bit newer than our minimum libvirt version support.

Good point. Guess it doesn't matter though if we have the two
alternatives you and Sean have suggested for figuring this stuff out?
The important thing is that release note. Setting 'chassis.serial'
would be a nice TODO if we have 4.1.0.

Stephen