On Fri, Dec 02, 2016 at 01:59:49PM +0000, 'Viktor Bachraty' via ganeti-devel
wrote:
> Migration is supported on KVM/Xen hypervisors only. Finalize methods are
> called in both success or suspected failure (the master node can't
> certainly know about failures - e.g. in case of timeouts). Thus these
> functions need to be as robust as possible in order to be able to
> recover from failures - in case success=False the functions should be
> conservative, trying to detect the actual state and idempotent. The
> cleanup workaround works for XM, on XL it is a no-op.
See inline...
> + else:
> + # Cleanup the most common failure case when the source instance fails
> + # to freeze and remains running as 'migrating-${oldname}' This works
> with
> + # XM, on XL it turns to a no-op.
I was going to ask if we could have a slightly less terse comment here maybe
say "because xl doesn't rename instances during migrate."
but then I remembered that xl *does* in fact rename source domains.
After the copy, xl renames the source domain to domain--migratedaway,
allows the target domain to resume, then destroys the source domain if the
target resumes properly. See
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/xl_cmdimpl.c;h=521b0b533833;hb=refs/heads/stable-4.4#l3685
There's a small window here where there's a domain--migratedaway on the source,
and the target didn't resume properly. Maybe we should have xl_temp_name and
xm_temp_name and attempt to _RenameInstance either one if they happen to exist?
Thanks,
Brian.
> + temp_name = 'migrating-' + instance.name
> + info = self.GetInstanceInfo(temp_name, hvparams=instance.hvparams)
> + if info:
> + self._RenameInstance(temp_name, instance.name, instance.hvparams)
>
> def GetMigrationStatus(self, instance):
> """Get the migration status
> --
> 2.8.0.rc3.226.g39d4020
>
