Le 9 mars 2020 à 14:03, Michal Privoznik <mprivozn@xxxxxxxxxx> a écrit : > > On 3/6/20 6:49 PM, Daniel P. Berrangé wrote: >>> On Fri, Mar 06, 2020 at 06:24:15PM +0100, Andrea Bolognani wrote: >>> Recently I've been working on integrating qemu:///embed into an >>> application. It's been reasonably smooth so far :) >>> >>> There's one thing, however, that has caused a bit of confusion, and >>> I would like to clarify whether my expectations are incorrect, there >>> are genuine bugs in the implementation that need to be addressed, or >>> maybe the experimental nature of embedded driver support results in >>> not all scenarios having yet been considered and catered for. >>> >>> Using virt-qemu-run as an example, when I run it as root I see that >>> >>> * the domain doesn't show up in the output of 'virsh list' for >>> qemu:///system; >> This is good. >>> * it does, however, show up in the output of 'machinectl', with >>> class=vm and service=libvirt-qemu; >> This is bad. It is one of the gaps we need to deal with. >> A long while back I proposed a domain XML option for this: >> https://www.redhat.com/archives/libvir-list/2017-December/msg00729.html >> <resource register="none|direct|machined|systemd"/> >> The "none" case meant inherit the cgroups placement of the parent >> libvirtd (or now the app using the embedded driver), and would be >> a reasonable default for the embedded case. >> For the other cases, we certainly need to do something to ensure >> uniqueness. This is possibly as simple as including a fixed >> prefix like "qemu-$PID" where $PID is the app embedding the >> driver. That said, we support closing the app, and re-starting >> using the same embedded driver directory, which would change >> PID. > > Instead of PID we can derive the value from the root path, e.g. i-node of the root dir or some substring of the path hash, say first 6 letters of md5($root_path). This would guarantee the stability of the prefix across app restarts (if we assume all root dirs to be on one FS so we don't have clashing i-node numbers). > Root path hash is more robust also in other cases, like file copy/rename often used for atomic updates. > Michal >
