On 1/22/2019 12:19 PM, Sean Mooney wrote:
you are specifically doing a resize so you dont need to regenerate a new xml on the source node before starting a live migration sice its not a live migration but you might want to premtpvily allcoate the pci devices on the destination if you want to prevent a race with other hosts. That said for stien it may be better to declare that out of scope. its really not any more racy then spawning an instace as we dont claim the device untill we get to the compute node anyway today.
Correct, and the plan for cross-cell resize is to do the same RT.resize_claim on the target host in the target cell before trying to move anything, which is the same thing we do in ComputeManager.prep_resize for a normal resize within the same cell.
the instance.numa_topology shoudl really be recalulated for the target host also. you do not want to require the destination host to place the vm with the original numa toptolgy from the source node. so i think you need to propagate the numa related request which are all in the flavor/image but i dont think you need to copy the instance numa_topology object. its not a live migration so provided the
The instance.numa_topology is calculated from the flavor and image during the initial server create: https://github.com/openstack/nova/blob/dd84e75260c3c919398536f7d05764713dc1c... And during the MoveClaim: https://github.com/openstack/nova/blob/dd84e75260c3c919398536f7d05764713dc1c... So yeah it looks like I don't really have to worry about updating/setting instance.numa_topology in the target cell DB during the resize although it seems pretty weird that we leave that stale information in the instances table during a resize (it's also stale in the RequestSpec - I think Alex Xu reported a bug for that). -- Thanks, Matt