<div dir="ltr">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<div>change the serial of instances that already exists. Should we have a way to preserve the serial for exisiting instances in order to not</div><div>cause any workload failue for our customers as changing the serial may cause some problem.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 26, 2019 at 7:30 PM Stephen Finucane <<a href="mailto:sfinucan@redhat.com">sfinucan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-01-25 at 18:52 -0600, Matt Riedemann wrote:<br>
> On 1/25/2019 10:35 AM, Stephen Finucane wrote:<br>
> > He noted that one would be a valid point in<br>
> > claiming the host OS identity should have been reported in<br>
> > 'chassis.serial' instead of 'system.serial' in the first place [1] but<br>
> > changing it now is definitely not zero risk.<br>
> <br>
> If I'm reading those docs correctly, chassis.serial was new in libvirt <br>
> 4.1.0 which is quite a bit newer than our minimum libvirt version support.<br>
<br>
Good point. Guess it doesn't matter though if we have the two<br>
alternatives you and Sean have suggested for figuring this stuff out?<br>
The important thing is that release note. Setting 'chassis.serial'<br>
would be a nice TODO if we have 4.1.0.<br>
<br>
Stephen<br>
<br>
<br>
</blockquote></div>