Open Stack

Thanks Tobias! I was wondering about this 'request_specs' table
before, and 'availability_zone' in its blob for those VMs were NULL
value IIRC, and I don't know how to update it before. I am not sure
how to use oslo_versionedobjects to update it.

So basically there would be no way for us to use new
'availability_zone' aggregate name later for hypervisor hosts?

I finally worked around this issue by removing hosts from new
availability zone name, which by default put those hosts back to
`nova` zone, and that ensured the live migration process working
again. This is not ideal, but is now working.

Thanks,
Hai

On Sun, Aug 8, 2021 at 3:44 AM Tobias Urdin <tobias.urdin at binero.com> wrote:
>
> Hello,
>
> The availability_zone field in the instances object is a read-only field that doesn’t have anything to do with
> the actual scheduling of instances. This has been covered numerous of times on the mailing list here.
>
> The request_specs table in the nova API database contains the specs for when an instance was launched and
> the JSON blob there (in the spec field) includes the field availability_zone which affects scheduling.
>
> Please not that it’s not supported or recommend to update that field and if you do it should be done using oslo_versionedobjects
> even though updating it directly in the database will make it appear to work but might not be without bugs.
>
> Best regards
>
> > On 6 Aug 2021, at 21:24, hai wu <haiwu.us at gmail.com> wrote:
> >
> > It seems this 'AvailabilityZoneFilter' is really buggy. The
> > 'instances' table 'availability_zone' field was already updated to
> > match the target desired zone name, but 'AvailabilityZoneFilter' kept
> > rejecting the request. I already restarted nova-api, nova-conductor,
> > nova-scheduler services after updating this database field value, but
> > that's not helpful.
> >
> > In the source code in file
> > '/usr/lib/python3/dist-packages/nova/scheduler/filters/availability_zone_filter.py',
> > how does 'spec_obj' got its availability_zone value? I don't
> > understand this particular code. This issue is really frustrating ..
> >    def host_passes(self, host_state, spec_obj):
> >        availability_zone = spec_obj.availability_zone
> >
> > On Wed, Aug 4, 2021 at 5:11 PM hai wu <haiwu.us at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> How to update existing vm instances 'availability_zone' field in nova
> >> database 'instances' table? It turns out there are many VMs with
> >> default 'nova' availability zone, while the hypervisors are with
> >> another different target aggregate/availability zone name, thus live
> >> migration for these VMs are failing.
> >>
> >> The strange thing is that the 'OS-EXT-AZ:availability_zone' output
> >> from 'openstack server show VM_NAME' is showing these VMs are already
> >> with the target availibity_zone name. No idea why we have this
> >> inconsistency.
> >>
> >> Would it be ok to just update database table entry directly to set
> >> 'availility_zone' to different value for these VMs? Or there might be
> >> better alternatives I am not aware of?
> >>
> >> Thanks,
> >> Hai
> >
>