> On 20 Jan 2026, at 8:45 PM, Peter Krempa <[email protected]> wrote: > > !-------------------------------------------------------------------| > CAUTION: External Email > > |-------------------------------------------------------------------! > > 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! > Hah!
> >>> >>>> >>>> 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. > Hi Peter, thanks for the dummy VM suggestion, I gave it a spin, and it seems to work! I’ll rework the patch-series keeping the approach in mind, and share it on the list soon. Regards, Tejus
