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: ...}

> > 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

> > 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?

> - 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

> - migration source prepare. > - do actually migration. Does libvirt python API have native support for that?

> - recover if failed. Probably, on fail, some leftovers will be on destination server. How will you do the clean up?

Will it be a communication between the Kimchi servers?

What about if the destination server does not have a Kimchi setup?

> - do finish if migration successful. > > > Comments are welcome! > -- > Yun Tong Jin, Simon > Linux Technology Center, Open Virtualization project > IBM Systems & Technology Group > jinyt(a)cn.ibm.com, Phone: 824549654

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?

> > -Simon >>> - do finish if migration successful. >>> >>> >>> Comments are welcome! >>> -- >>> Yun Tong Jin, Simon >>> Linux Technology Center, Open Virtualization project >>> IBM Systems & Technology Group >>> jinyt(a)cn.ibm.com, Phone: 824549654 >> > > > -- > Yun Tong Jin, Simon > Linux Technology Center, Open Virtualization project > IBM Systems & Technology Group > jinyt(a)cn.ibm.com, Phone: 824549654 _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

在 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.

>> >>> >>> -Simon >>>>> - do finish if migration successful. >>>>> >>>>> >>>>> Comments are welcome! >>>>> -- >>>>> Yun Tong Jin, Simon >>>>> Linux Technology Center, Open Virtualization project >>>>> IBM Systems & Technology Group >>>>> jinyt(a)cn.ibm.com, Phone: 824549654 >>>> >>> >>> >>> -- >>> Yun Tong Jin, Simon >>> Linux Technology Center, Open Virtualization project >>> IBM Systems & Technology Group >>> jinyt(a)cn.ibm.com, Phone: 824549654 >> >> >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: > lagarcia(a)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. _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

As migration over TCP required libvirt config modification on destination, the workaround is migrate via ssh which only required ssh connection to destination. option 1: manually do ssh authentication with sth like ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote option 2: Require user/password of destination server and kimchi will do the ssh authentication with: sshpass -p password ssh-copy-id -i ~/.ssh/id_rsa.pub root@remote Issue: With kimchi authentication via LAPD, the user/password won't exist on destination server.

Any thoughts ? -Simon 于 2014年10月28日 18:03, simonjin 写道: > The problem is how to do authentication between two peers, > which requires libvirtd conf modification on destination and SASL setup > > From libvirtd.conf: > /# Listen for unencrypted TCP connections on the public TCP/IP port.// > //# NB, must pass the --listen flag to the libvirtd process for this to// > //# have any effect.// > //#// > //# Using the TCP socket requires SASL authentication by default. Only// > //# SASL mechanisms which support data encryption are allowed. This is// > //# DIGEST_MD5 and GSSAPI (Kerberos5)// > //#// > //# This is disabled by default, uncomment this to enable it.// > //listen_tcp = 1/ > > -Simon > > 在 2014年10月24日 15:28, Zhou Zheng Sheng 写道: >> on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: >>> lagarcia(a)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. >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel