Hi, Sylvain Nova guys,
Our team has also argued about this deeply, and no consensus was reached.
if instance.az is designed just for a reflect of the instance at boot
time, then it doesn't make any sense after the vm is live-migrated
with specified destination for several times, right?
Then, how
Hi.
Currently, when performing live-migration the AZ of the instance didn't update.
In usecase like this:Instance_1 is in host1 which is in az1, we live-migrate it
to host2 (provide host2 in API request) which is in az2. The operation will
secusess but the availability zone data stored in
Hi,
Thanks for the reply, one possible usecase is that user wants to
live-migrate to az2 so he specified host2. As we didn't update the
instance.az, if the user live-migrate again without specifiying destination
host, the instance will migrate to az1 again, this might be different as
the user
Le 23/09/2015 08:56, Feodor Tersin a écrit :
Hi.
/Currently, when performing live-migration the AZ of the instance
didn't update. In usecase like this:/
/Instance_1 is in host1 which is in az1, we live-migrate it to
host2 (provide host2 in API request) which is in az2. The
Le 23/09/2015 05:24, Zhenyu Zheng a écrit :
Hi, all
I have a question about availability zones when performing live-migration.
Currently, when performing live-migration the AZ of the instance
didn't update. In usecase like this:
Instance_1 is in host1 which is in az1, we live-migrate it to
Hi, all
I have a question about availability zones when performing live-migration.
Currently, when performing live-migration the AZ of the instance didn't
update. In usecase like this:
Instance_1 is in host1 which is in az1, we live-migrate it to host2
(provide host2 in API request) which is in
