On 07/08/20 13:24, Muneendra Kumar M wrote: > Hi Paolo, > Below are my replies. > >>> 3.As part of this interface user/deamon will provide the details of >>> VM such as UUID,PID on VM creation to the transport . >>> The VM process, or the container process, is likely to be >>> unprivileged and cannot obtain the permissions needed to do this; >>> therefore, you need to cope with the situation where there is no PID >>> yet in the cgroup, because the tool >that created the VM or container >>> might be initializing the cgroup, but it might not have started the >>> VM yet. In that case there would be no PID. >> >> Agreed.A >> small doubt. If the VM is started (running)then we can have the PID and >> we >> can use the PID? >> Yes, but it's too late when the VM is started. In general there's no >> requirement that a cgroup is setup shortly before it is populated. > > This should be ok . > > The fabric interface just provides a mechanism to store user > specific data into a pid blkcg > > Before the daemon issues the UUID and pid to the fabric interface, it needs > to check whether the VM is in running state or not. > > If it the VM is in running state then only it issues the VM details. > > And if the cgroup's are not setup as you mentioned the interface will > return a failure(with a proper logs) and the daemon will retry after some > time. > > And this also helps us to keep track of PID to UUID mapping at daemon level. Why would that be useful? Again, the mapping of the UUID is _not_ to a PID, it is to a cgroup. There is no concept of a VM PID; you could legitimately have I/O in a separate process than say the QEMU process, and that I/O process could legitimately reside in a separate blkcg than QEMU. There is no need for any daemon, and I'm not even sure which daemon would be handling this. App identifier should be purely a kernel concept with no userspace state. Paolo
