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. >> Also what would the kernel API look like for this? Would it have to >> be driver-specific? > > The API should be generic and it should not be driver-specific. >So it would be a new file in /dev, whose only function is to set up a UUID >for a cgroup? I will work with James Smart and check whether we can use any of the existing interface for the same and will share the details. >Paolo Regards, Muneendra.
