openstack server show <instance name/id> -c config_drive
On 11/29/23 17:34, Nguyễn Hữu Khôi wrote:
Hi,I am using share storage for Octavia instance.
Do you mind elaborating the "share strage" here ?
Are you using volume backed amphora or shared storage in your compute nodes ?
In case you have shared storage among some compute nodes then I'd suggest you check
source-destination compute nodes and see whether these two nodes are actually using
the same shared storage for instance data (usually located at /var/lib/nova/instances )
If you are using volume backed amphora then I may check the libvirt xml of the amphora
instance and also the nova flavor used, to find out any local disk device attached
(eg. If the flavor has swap then it may attach an additional local device)
We can mv Octavia instances by failover but if there is a hundred of lb then it will be a big problem. I am planning to use specific computers for Octavia only and use Active-Standby Topologies.
Nguyen Huu Khoi
On Wed, Nov 29, 2023 at 3:16 PM Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:
This is not an issue with Octavia but is more about usage of Nova.
By default, amphora instances are deployed using image boot, and use
ephemeral disks stored in compute nodes. Unless you have a shared storage
in your compute nodes to store ephemeral disks(nfs, ceph and so on),
you have to enable block-migration to live migrate the instance.
(See --block-migration option in openstack CLI)
However, AFAIK the general recommendation is to try amphora failover
(which internally recreates the amphora instance) instead of live-migrating it,
as is described in the guide[1]. You might want to try that method instead.
[1] https://docs.openstack.org/octavia/latest/admin/guides/operator-maintenance.html#evacuating-a-specific-amphora- from-a-host
On 11/29/23 14:17, Nguyễn Hữu Khôi wrote:
Hello everyone.
I deploy amphora instances using shared storage but when I do live migrate it to another host, I encounter this error.
compute12 is not on shared storage: Shared storage live-migration requires either shared storage or boot-from-volume with no local disks
Woud we have a solution for this?
Thank you.
Nguyen Huu Khoi