yahoo-eng-team team mailing list archive

[Sylvain Bauza <sbauza@xxxxxxx>]

This shouldn't be accepted. 
If you create an instance by asking a specific AZ, the design is that you can't migrate it to another AZ unless you force it.

When calling live-migrate by the latest API microversion, even with
asking to go to a specific host, Nova wouldn't accept it.

See https://docs.openstack.org/nova/latest/admin/availability-zones.html
#implications-for-moving-servers for knowing more about the design.

Closing this bug.

** Changed in: nova
       Status: In Progress => Invalid

** Changed in: nova
       Status: Invalid => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1861964

Title:
  availability_zone in request_specs not updated when live migrate vm
  from one availability zone to another

Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  availability_zone in request_specs not updated when live migrate vm
  from one availability zone to another, and if the old aggregate's host
  demount, vm migration will be failed.

  Steps to reproduce
  ==================

  1) create aggregation: aggregate01 using AZ: zone01, and bonding cmp001;
  2) create aggregation: aggregate02 using AZ: zone02, and bonding cmp002;
  3) create flavor: test_flavor01, and set properties fit to aggregate01/aggregate02;
  4) create instance: test_vm01 using test_flavor01 and --availability-zone set to zome01;
  5) check OS-EXT-AZ:availability_zone using 'openstack server show test_vm01' is set to zone01, and the vm's availability_zone in request_specs is set to zone01 too.
  6) live migrate test_vm01 to cmp002;
  7) check OS-EXT-AZ:availability_zone using 'openstack server show test_vm01' is set to zone02, but the vm's availability_zone in request_specs is still zone01.
  8) demount cmp001 on aggregate01, then bonding cmp001 to aggregate02;
  9) live migrate test_vm01 without given target node will be failed. because availability_zone in request_specs is still zone01.

  I think the value of availability_zone in request_specs should be
  updated, and the vms should use new availability_zone in request_specs
  when scheduling.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1861964/+subscriptions