[RFC REPOST 0/7] introduce support for live appid updates

Pavel Hrdina posted 7 patches 2 weeks, 1 day ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/cover.1631203909.git.phrdina@redhat.com
docs/manpages/virsh.rst          | 14 ++++++
include/libvirt/libvirt-domain.h |  4 ++
src/conf/domain_validate.c       | 42 ++++++++++--------
src/conf/domain_validate.h       |  2 +
src/driver-hypervisor.h          |  6 +++
src/libvirt-domain.c             | 44 +++++++++++++++++++
src/libvirt_private.syms         |  2 +
src/libvirt_public.syms          |  1 +
src/qemu/qemu_cgroup.c           | 17 +-------
src/qemu/qemu_driver.c           | 75 ++++++++++++++++++++++++++++++++
src/remote/remote_driver.c       |  1 +
src/remote/remote_protocol.x     | 14 +++++-
src/remote_protocol-structs      |  6 +++
src/util/vircgroup.c             | 24 ++++++++++
src/util/vircgroup.h             |  3 ++
tools/virsh-domain.c             | 65 +++++++++++++++++++++++++++
16 files changed, 286 insertions(+), 34 deletions(-)

[RFC REPOST 0/7] introduce support for live appid updates

Posted by Pavel Hrdina 2 weeks, 1 day ago
Rebased on top of current master.

I'm posting this as an RFC mainly because I'm not sure how to model
the new API. This patches introduce a new naive API that will change
only the APPID and nothing else.

Currently there are no other known features related to Fibre Channel
resources so this non-extendable API will be sufficient, however the
appid lives in <resource> element in the XML where we currently have
root cgroup partition. Even though changing the partition will not be
supported and we don't know about anything else that could be placed
here it doesn't mean it will not happen in the future. In that case
we would have to add new API as well.

So I'm wondering if we should create a more generic API that would take
typed parameters as arguments:

int virDomainSetResource(virDomainPtr domain,
                         virTypedParameterPtr params,
                         int nparams,
                         unsigned int flags)

Any ideas?

Pavel Hrdina (7):
  conf: extract appid validation to virDomainDefResourceAppidValidate
  cgroup: extract setting fibre channel appid into virCgroupSetFCAppid
  virCgroupSetFCAppid: properly handle when appid is NULL
  src: introduce virDomainSetFibreChannelAppid API
  remote: add RPC support for the virDomainSetFibreChannelAppid API
  qemu: implement virDomainSetFibreChannelAppid API
  tools: introduce virsh setappid command

 docs/manpages/virsh.rst          | 14 ++++++
 include/libvirt/libvirt-domain.h |  4 ++
 src/conf/domain_validate.c       | 42 ++++++++++--------
 src/conf/domain_validate.h       |  2 +
 src/driver-hypervisor.h          |  6 +++
 src/libvirt-domain.c             | 44 +++++++++++++++++++
 src/libvirt_private.syms         |  2 +
 src/libvirt_public.syms          |  1 +
 src/qemu/qemu_cgroup.c           | 17 +-------
 src/qemu/qemu_driver.c           | 75 ++++++++++++++++++++++++++++++++
 src/remote/remote_driver.c       |  1 +
 src/remote/remote_protocol.x     | 14 +++++-
 src/remote_protocol-structs      |  6 +++
 src/util/vircgroup.c             | 24 ++++++++++
 src/util/vircgroup.h             |  3 ++
 tools/virsh-domain.c             | 65 +++++++++++++++++++++++++++
 16 files changed, 286 insertions(+), 34 deletions(-)

-- 
2.31.1

Re: [RFC REPOST 0/7] introduce support for live appid updates

Posted by Michal Prívozník 2 weeks ago
On 9/9/21 6:13 PM, Pavel Hrdina wrote:
> Rebased on top of current master.
> 
> I'm posting this as an RFC mainly because I'm not sure how to model
> the new API. This patches introduce a new naive API that will change
> only the APPID and nothing else.
> 
> Currently there are no other known features related to Fibre Channel
> resources so this non-extendable API will be sufficient, however the
> appid lives in <resource> element in the XML where we currently have
> root cgroup partition. Even though changing the partition will not be
> supported and we don't know about anything else that could be placed
> here it doesn't mean it will not happen in the future. In that case
> we would have to add new API as well.
> 
> So I'm wondering if we should create a more generic API that would take
> typed parameters as arguments:
> 
> int virDomainSetResource(virDomainPtr domain,
>                          virTypedParameterPtr params,
>                          int nparams,
>                          unsigned int flags)

I think having the spcific API as you implemented is fine for now. We
did not have much in <resource/> until now and I don't think we will in
foreseeable future.

> 
> Any ideas?
> 
> Pavel Hrdina (7):
>   conf: extract appid validation to virDomainDefResourceAppidValidate
>   cgroup: extract setting fibre channel appid into virCgroupSetFCAppid
>   virCgroupSetFCAppid: properly handle when appid is NULL
>   src: introduce virDomainSetFibreChannelAppid API
>   remote: add RPC support for the virDomainSetFibreChannelAppid API
>   qemu: implement virDomainSetFibreChannelAppid API
>   tools: introduce virsh setappid command
> 
>  docs/manpages/virsh.rst          | 14 ++++++
>  include/libvirt/libvirt-domain.h |  4 ++
>  src/conf/domain_validate.c       | 42 ++++++++++--------
>  src/conf/domain_validate.h       |  2 +
>  src/driver-hypervisor.h          |  6 +++
>  src/libvirt-domain.c             | 44 +++++++++++++++++++
>  src/libvirt_private.syms         |  2 +
>  src/libvirt_public.syms          |  1 +
>  src/qemu/qemu_cgroup.c           | 17 +-------
>  src/qemu/qemu_driver.c           | 75 ++++++++++++++++++++++++++++++++
>  src/remote/remote_driver.c       |  1 +
>  src/remote/remote_protocol.x     | 14 +++++-
>  src/remote_protocol-structs      |  6 +++
>  src/util/vircgroup.c             | 24 ++++++++++
>  src/util/vircgroup.h             |  3 ++
>  tools/virsh-domain.c             | 65 +++++++++++++++++++++++++++
>  16 files changed, 286 insertions(+), 34 deletions(-)
> 

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

Michal

Re: [RFC REPOST 0/7] introduce support for live appid updates

Posted by Daniel P. Berrangé 2 weeks ago
On Thu, Sep 09, 2021 at 06:13:16PM +0200, Pavel Hrdina wrote:
> Rebased on top of current master.
> 
> I'm posting this as an RFC mainly because I'm not sure how to model
> the new API. This patches introduce a new naive API that will change
> only the APPID and nothing else.
> 
> Currently there are no other known features related to Fibre Channel
> resources so this non-extendable API will be sufficient, however the
> appid lives in <resource> element in the XML where we currently have
> root cgroup partition. Even though changing the partition will not be
> supported and we don't know about anything else that could be placed
> here it doesn't mean it will not happen in the future. In that case
> we would have to add new API as well.

I'm curious why we need to even support updates for the APPID in
the first place. I understood it to be a unique identifier for
the VM from POV of the storage, and unique identifier are not
something you would typically change on the fly.


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