[one-users] Pre-migrate and post-migrate actions

[Tino Vazquez]

Hi Székelyi,

We are currently in the process of releasing next version of OpenNebula, and
I am afraid we won't have time to look into this for 1.6.

I encourage you to use a hack for now in the vmm_kvm driver, we will come
back to support this in the core since it seems a reasonable thing to have.

Best regards,

-Tino

--
Constantino Vázquez Blanco | dsa-research.org/tinova
Virtualization Technology Engineer / Researcher
OpenNebula Toolkit | opennebula.org


2010/7/8 Székelyi Szabolcs <szekelyi at niif.hu>

> Hi,
>
> any news on this? Actually this issue is blocking our progress in a
> project,
> so we'd really like to hear your opinion. Maybe I forgot to write that we'd
> willingly fix this ourselves and then contribute the changes back to
> OpenNebula. We're seeking your advice to make sure that the work we put
> into
> this conforms to your plans, standards and requirements.
>
> Note that we ran into the same problem recently in relation to setting up
> the
> ebtables-based network for VMs on live migration. [0]
>
> Thanks,
> --
> cc
>
> [0] http://lists.opennebula.org/pipermail/users-opennebula.org/2010-
> July/002303.html
>
> On Wednesday 23 June 2010 20.09.23 Székelyi Szabolcs wrote:
> > Hello,
> >
> > we faced a problem and thought about more than one ways to fix it,
> > unfortunately they require source modification. We would like to know
> your
> > opinion.
> >
> > The problem is that we'd like to use iSCSI targets to store the VMs'
> disks,
> > one target per VM. The idea is that if a VM starts running on a host,
> then
> > the host logs in to the corresponding iSCSI target, thus sees the disk
> > images for that VM.
> >
> > This works now, we're able to do this with a custom TM driver. The
> problem
> > is with live migration. Unfortunately we found no possibility to make ONE
> > call a trigger that logs in to the target on the destination host right
> > before live migration starts, which means the VM is unable to start on
> the
> > new host.
> >
> > The most clear solution seems to be to make LCM call not just the VMM to
> do
> > the migration, but the TM driver beforehand [1] [2]. Due to the
> > asynchronous nature of LCM, new VM states must be introduced, just like
> as
> > it is done now with non-live migration.
> >
> > Another possibility is to hack VirtualMachineManager or
> > VirtualMachineManagerDriver to somehow run the appropriate commands
> before
> > (and after) migration, before returning the result to the LCM.
> >
> > The third and most ugly way would be to hack one_vmm_kvm.rb (yes, we're
> > using KVM) to do the job.
> >
> > What is your opinion about the way to implement this?
> >
> > Thanks,
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20100708/9fdee9f2/attachment-0003.htm>