Kimchi migration within peers
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 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.'), 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 . - connect migration destination, guest vm config/params transfer and setup. - migration source prepare. - do actually migration. - recover if failed. - do finish if migration successful. Comments are welcome! -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
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@cn.ibm.com, Phone: 824549654
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?
- 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?
Will wrapper the native libvirt python API and put it in a task. 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. -Simon
- do finish if migration successful.
Comments are welcome! -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
-- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@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?
- 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?
Will wrapper the native libvirt python API and put it in a task. 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@cn.ibm.com, Phone: 824549654
-- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
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?
- 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?
Will wrapper the native libvirt python API and put it in a task. 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?
-Simon
- do finish if migration successful.
Comments are welcome! -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
-- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@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?
- 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?
Will wrapper the native libvirt python API and put it in a task. 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@cn.ibm.com, Phone: 824549654
-- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
lagarcia@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?
- 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?
Will wrapper the native libvirt python API and put it in a task. 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
-Simon
- do finish if migration successful.
Comments are welcome! -- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
-- Yun Tong Jin, Simon Linux Technology Center, Open Virtualization project IBM Systems & Technology Group jinyt@cn.ibm.com, Phone: 824549654
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote:
lagarcia@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?
> - 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?
Will wrapper the native libvirt python API and put it in a task. 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.
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 写道:
在 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
lagarcia@br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote: 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
on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: 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@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 ??:
? 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
lagarcia@br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote: 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
on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 10/31/2014 07:18 AM, simonjin wrote:
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.
Sorry, but I didn't understand the LDAP implication on it. Kimchi authentication does not impact the system authentication. So the migration API should be something like: POST /vms/my-vm/migrate {host: my-dest-host, username: dest-host-username, password: my-password} username and password as the values needed to SSH to the destination host. It will not depend on Kimchi authentication.
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 写道:
在 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
lagarcia@br.ibm.comn 10/23/2014 08:43 AM, simonjin wrote: 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
on 2014/10/23 22:38, Leonardo Augusto Guimarães Garcia wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Leonardo Augusto Guimarães Garcia -
simonjin -
Zhou Zheng Sheng