[Kimchi-devel] Kimchi migration within peers
Zhou Zheng Sheng
zhshzhou at linux.vnet.ibm.com
Fri Oct 24 07:28:18 UTC 2014
on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote:
>
> lagarcia at br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote:
>>
>> 在 2014年10月22日 20:28, Aline Manera 写道:
>>>
>>> On 10/22/2014 10:20 AM, Aline Manera wrote:
>>>>
>>>> On 10/22/2014 07:24 AM, simonjin wrote:
>>>>> On 10/22/2014 01:48 AM, Aline Manera wrote:
>>>>>>
>>>>>> On 10/20/2014 12:50 AM, simonjin wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm presenting here my proposal for the feature "Guest migration"
>>>>>>> which
>>>>>>> is expected to be implemented for Kimchi 1.4.
>>>>>>>
>>>>>>>
>>>>>>> Description
>>>>>>>
>>>>>>> Migrate guest vm within peer/host discovered by Kimchi peers
>>>>>>> using openSLP.
>>>>>>> In the first stage 1, only do migration will be supported,
>>>>>>> in stage2, migrateCancel and migrateMonitor will be supported.
>>>>>>>
>>>>>>> *Migration Mode: *
>>>>>>> 1. Support libvirt tunnelled transport managed by direct migration.
>>>>>>> 2. Only support Live migration mode.
>>>>>>> 3. Only support migration over TCP
>>>>>>>
>>>>>>> *Migration Capability Check*
>>>>>>> - Source libvirtd/client should be able to connect destination
>>>>>>> libvirtd.
>>>>>>> - CPU architectures compare(X86 vs PPC).
>>>>>>> - No PCI device passthrough.
>>>>>>> - In a shared storage pool and the pool can be access/write by
>>>>>>> destination.
>>>>>>>
>>>>>>>
>>>>>>> REST API
>>>>>>>
>>>>>>> Only one new REST command will be added in stage 1.
>>>>>>>
>>>>>>>
>>>>>>> Syntax
>>>>>>>
>>>>>>> POST /vms//<vm-name>//migrate
>>>>>>
>>>>>> You will have a data object informing the destination host
>>>>>>
>>>>>> POST /vms/<vm-name>/migrate {host: ...}
>>>>>>
>>>>> ok, the json data will be {host:ip, user:username, passwd:password}
>>>>>
>>>>>>>
>>>>>>> Parameters:
>>>>>>>
>>>>>>
>>>>>>> in config.py.in:
>>>>>>>
>>>>>>> ('migration_destination_timeout', '21600',
>>>>>>> 'Maximum time the destination waits for the migration
>>>>>>> to finish.
>>>>>>> 21600 should be enough since all the peers will be in
>>>>>>> the same LAN'),
>>>>>>>
>>>>>>> ('migration_max_bandwidth', 'unlimited',
>>>>>>> 'default in libvirt is unlimited'),
>>>>>>>
>>>>>>> ('migration_downtime', '500',
>>>>>>> 'Maxmium allowed downtime for live migration in
>>>>>>> milliseconds '
>>>>>>> '(anything below 100ms is ignored) if you do not care
>>>>>>> about '
>>>>>>> 'liveness of migration, set to a very high value,
>>>>>>> such as '
>>>>>>> '600000.'),
>>>>>>
>>>>>> I don't think we need to allow user edits those values so there is
>>>>>> no need to add them to config.py.in
>>>>>>
>>>>> It's better to put them in kimchi.conf to allow user to edit just
>>>>> in case the migration failed due to them.
>>>>>
>>>>>>>
>>>>>>> Return:
>>>>>>>
>>>>>>> An asynchronous Task with "target_uri" containing
>>>>>>> "/vms/</new-vm-name/>".
>>>>>>> As expected with any Task, the cloning process can be tracked by
>>>>>>> checking the corresponding task's status.
>>>>>>>
>>>>>>> *Do_migration step:*
>>>>>>> - migration source check .
>>>>>>
>>>>>> What kind of verification will be done?
>>>>>> Storage pool and network? Guest permission settings?
>>>>>>
>>>>> will do *Migration Capability Check *described above*.
>>>>>
>>>>> *
>>>>>>> - connect migration destination, guest vm config/params transfer
>>>>>>> and setup.
>>>>>>
>>>>>> How will it be done?
>>>>>> From libvirt doc, I can see different types of migration, which
>>>>>> one is the best solution for Kimchi?
>>>>>>
>>>>>> For reference: http://libvirt.org/migration.html
>>>>>>
>>>>> It will be tunneled + P2P migration,
>>>>> so the API will be like:
>>>>> do_migrate = dom.migrateToURI2(dest, muri, None,
>>>>> libvirt.VIR_MIGRATE_LIVE |
>>>>> libvirt.VIR_MIGRATE_PEER2PEER |
>>>>> libvirt.VIR_MIGRATE_TUNNELLED |
>>>>> libvirt.VIR_MIGRATE_ABORT_ON_ERROR,
>>>>> None, maxbandwidth)
>>>>>
>>>>>>> - migration source prepare.
>>>>>>> - do actually migration.
>>>>>>
>>>>>> Does libvirt python API have native support for that?
>>>>>>
>>>>> Will wrapper the native libvirt python API and put it in a task.
>>>>>>> - recover if failed.
>>>>>>
>>>>>> Probably, on fail, some leftovers will be on destination server.
>>>>>> How will you do the clean up?
>>>>> Will destroy remote vm instance on destination and resume source vm
>>>>> is being paused.
>>>>>> Will it be a communication between the Kimchi servers?
>>>>> the migration communication will be between to libvirtd.
>>>>>> What about if the destination server does not have a Kimchi setup?
>>>>>>
>>>>> the destination server is discovered by kimchi, which will guaranty
>>>>> it has a kimchi setup.
>>>>
>>>> So can not I migrate my guest to a new server without Kimchi?
>>>
>>> What about I am migrating from Kimchi to ovirt/openstack?
>>>
>> Migration should be only between kimchi peers,
>> there is no way to migrate to ovirt/openstack host via kimchi API.
> I agree there is no way to migrate to oVirt/OpenStack. However, from our
> perspective, this should not matter.
>
> As you said on your proposal "Source libvirtd/client should be able to
> connect destination libvirtd.". So, the only thing that should matter is
> whether we have a libvirt running on the other side or not. This is what
> we need to check (and I think libvirt API checks this for us and return
> an error if it doesn't find a libvirt running on the destination). From
> a migration perspective, it doesn't matter if the destination is running
> Kimchi, oVirt, OpenStack or any other management tool. We should only
> check if libvirt is running and, if it is running and the migration is
> successful, we are good.
>
> On the Kimchi UI, we will, of course, have an easy way to select a
> Kimchi peer and migrate to it if Federation is on and other peers have
> discovered but we need to give the option to the user, IMO, to select an
> arbitrary IP where they know libvirt is running to migrate the VM to
> that host.
>
> Best regards,
>
> Leonardo Garcia
In my opinion, it would be very nice to support migrate to any host with
libvirtd. This makes Kimchi easily integrated into other projects. I
think we can implement migration targeting at libvirt level. Kimchi
peers discovery are just to provide a host list for user's convenience.
We can also make Kimchi check and configure libvirt to be able to accept
migration connection.
More information about the Kimchi-devel
mailing list