> And I was talking about the above PIDS(3627) to be passed to the > interface along with UUID. >The cgroup exists even before the VM is started and waiting for the PID to >appear would be racy. The PID is *not* a representation of the VM, the >cgroup is (or at least it's the closest thing). >Using the PID would lead to an API that is easy to misuse. For example say >you have a random QEMU process that has not been placed in a cgroup, for >whatever reason. If someone doesn't understand that the API uses the PID > >just as a proxy for the cgroup, they could end up classifying *all traffic >from the host* with the VMID. If the API uses cgroups as the fundamental >concept instead, it's much harder to make this mistake. Agreed: So from the user we need to provide UUID and the cgroup associated info with VM to the kernel interface. Is this correct? There is no issues with UUID passing as one of the arg. Coming to the other cgroup associated VM here are the options which we can send 1)openfd: We need a utility which opens the cgroup path and pass the fd details to the interface. And we can use the cgroup_get_from_fd() utility to get the associated cgroup in the kernel. Dependent on utilty. 2)cgroupid:From the userspace iam not sure if there is any syfs/proc/sytem call interface which give us the cgroup id directly. Tejun correct me if iam wrong.If there is any such interface please let me know so that I can pass the same. 3)give the complete cgroup path associated with VM and the kernel interface will get the associated blkcg. The user needs to pass the path and the uuid info to the sysfs interface provided by the fabric interface The interface will write the uuid info in blkcg associated with cgroup path with the help of cgroup_get_from_path(). And there is no dependency on any utility. The user can simply pass the details using sysfs. Need your inputs on the same which one to use (openfd/cgroupid/path) . Regards, Muneendra.
