On Mon, Jan 19, 2026 at 14:08:29 +0000, Tejus GK wrote: > > On 14 Jan 2026, at 9:00 PM, Peter Krempa <[email protected]> wrote: > > > > !-------------------------------------------------------------------| > > CAUTION: External Email > > > > |-------------------------------------------------------------------!
Oh no! [...] > > > >> > >> Hence, virDomainFDStore is there to store FDs associated with the “name” > >> key, rather than the domain. > > > > Okay but that will make things much more complex due to our ACL stuff. > > > > Allowing to pass any FD means that any user (even those who can't see > > the VM) could pass a FD and theoretically siphon data off from it. > > > > I don't think we want to have a 'global' FD pool to pass. In case of > > migration I'd either suggest to define the VM (with possibly a dummy > > definition) just to have the domain object available. Alternatively we > > should have a migration API allowing FD passing. > > Hi Peter, > Thank you for the suggestion! I wanted to clarify that my design of > maintaining a global pool of FDs, was so to seamlessly support the use case > for managed P2P migrations. > > > I'd either suggest to define the VM (with possibly a dummy definition) > Is this workflow supported in P2P migrations? Also, we would have to at some > point of time, blow up the VM definition to match the one on the source, does > libvirt have support for that? Yes, ... > > Alternatively we should have a migration API allowing FD passing. > Hmm, even if we go ahead and implement that, I’m wondering how to make it > work for P2P managed migrations. Since, source libvirt won’t be able to pass > on FDs to the destination host. Thoughts? you need to open another new client connection on the destination and pass the FDs. In fact that's requrired since FD passing works only locally and the remote daemon is thus unable to do that. For now you can test it for FD-passed disks, where prior to migration you open a new connection and pass the FDs then kick off the migration This is a complex deployment where you do need to set up stuff on the destination manually so IMO this is a reasonable trade-off.
