[PATCH 01/12] migration/migration-pin: get migration pid for migration pin

[Daniel P. Berrangé]

On Tue, Jan 10, 2023 at 07:30:08PM +0800, Jiang Jiacheng wrote:
> 
> 
> On 2023/1/9 22:46, Daniel P. Berrangé wrote:
> > On Tue, Jan 03, 2023 at 09:08:20PM +0800, Jiang Jiacheng wrote:
> >> From: zhengchuan <zhengchuan at huawei.com>
> >>
> >> Firstly, we need to get migration pids, add
> >> virDomainMigrateGetMigrationPids() for migration pin.
> >>
> >> Signed-off-by:zhengchuan<zhengchuan at huawei.com>
> >> ---
> >>  include/libvirt/libvirt-domain.h |  3 +++
> >>  src/driver-hypervisor.h          |  5 ++++
> >>  src/libvirt-domain.c             | 39 ++++++++++++++++++++++++++++++++
> >>  src/libvirt_public.syms          |  5 ++++
> >>  src/qemu/qemu_domain.c           |  2 ++
> >>  src/qemu/qemu_domain.h           |  2 ++
> >>  src/qemu/qemu_driver.c           | 31 +++++++++++++++++++++++++
> >>  src/remote/remote_driver.c       |  1 +
> >>  src/remote/remote_protocol.x     | 17 +++++++++++++-
> >>  src/remote_protocol-structs      |  8 +++++++
> >>  10 files changed, 112 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
> >> index 295fd30c93..e11f2795f1 100644
> >> --- a/include/libvirt/libvirt-domain.h
> >> +++ b/include/libvirt/libvirt-domain.h
> >> @@ -6457,4 +6457,7 @@ int virDomainStartDirtyRateCalc(virDomainPtr domain,
> >>                                  int seconds,
> >>                                  unsigned int flags);
> >>  
> >> +char *virDomainMigrateGetMigrationPids(virDomainPtr domain,
> >> +                                       unsigned int flags);
> > 
> > Exposing QEMU thread PIDs in the public libvirt API is not something
> > we should be doing. We've explicitly aimed to avoid exposing the notion
> > of PIDs in our API in general.
> > 
> 
> Thanks for your reply!
> 
> As we should not exposing QEMU thread PIDs, is it a better way to
> proactively detect the PIDs of the qemu migration thread?
> For example, using QMP command during migration to detect the QEMU
> migration thread PIDs like iothreadpin does. Compared to QEMU event,
> detecting proactively may spend more time to complete migration pin,
> but i think its still makes sense for migration.

iothreadpin doesn't take thread PIDs, it takes integer
identifiers associated with the threads.

Why does the mgmt app need to know the migration PIDs ? The
API for setting pinning in the next patch doesn't accept a
PID, and we don't need to set different pinning for each
migration thread. Only libvirt QEMU driver code needs to
know the PIDs, not the libvirt public API/mgmt app.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|