Re: [PATCH v2 1/4] qemu.conf changes to support multiple memory backend

Hi All, This is just a heads up: I will be changing employment soon, so my Akamai email address will cease to operate this week. My personal email: michael(a)flatgalaxy.com. I'll re-subscribe later once I have come back online to work soon. Thanks! - Michael On 10/23/24 10:34, Michael Galaxy wrote: > On 10/2/24 02:54, Martin Kletzander wrote: >> On Sun, Sep 08, 2024 at 08:00:02AM +0200, Martin Kletzander wrote: >>> On Thu, Aug 15, 2024 at 01:30:38PM -0500, Michael Galaxy wrote: >>>> On 8/7/24 10:10, Michael Galaxy wrote: >>>>> On 8/7/24 08:23, Martin Kletzander wrote: >>>>>> Exactly, we do not want the paths to change.  But if you start >>>>>> the VM, >>>>>> then stop virtqemud/libvirtd (totally supported), change the >>>>>> config file >>>>>> to point to a different directory (or even different number of >>>>>> directories, I haven't even thought of that), then start the >>>>>> daemon back >>>>>> again, we'll have a problem when the VM is being cleaned up. >>>>>> >>>>>> For these kinds of situations we are keeping more pieces of >>>>>> information >>>>>> about running domains in a so called status XML.  This is saved >>>>>> on disk, >>>>>> but unavailable to the user so saving something there does not >>>>>> explicitly expose it to the user.  Having the paths saved there >>>>>> would >>>>>> make it nicer to clean up and it should've probably been done >>>>>> even with >>>>>> that one path that is supported nowadays.  I can have a look at >>>>>> fixing >>>>>> that at first and then your patches could be applied on top of >>>>>> that fix >>>>>> if that's fine with you or you can have a look at tackling that >>>>>> yourself, it should not be difficult, tests for that should be >>>>>> nice to >>>>>> write as well, it just needs to be done in a back-compat way, of >>>>>> course. >>>>>> >>>>>> See qemuDomainObjPrivateXMLFormat() and >>>>>> qemuDomainObjPrivateXMLParse() >>>>>> for some starting points. >>>>> >>>> I've finished addressing most of the rest of the review comments here >>>> and I'll >>>> sent that out, but I'd like to avoid too many more revisions here. >>>> >>>> IMHO, the problem above is really orthogonal to this feature and, >>>> as you >>>> said, >>>> applies to the original (single path) case, so I'd like to leave >>>> that as >>>> a homework >>>> assignment to the community. >>>> >>> >>> Yes, but once we start changing things it is harder to fix them. >>> >>>> Realistically, in a well-managed cloud, this is highly unlikely to >>>> happen, so I'm >>>> not too worried about it. >>>> >>> >>> I am not talking about accidental changes.  It is fine until someone >>> "really needs" to change that value and expects libvirt to behave >>> correctly. >>> >>>> Would a ticket be helpful somewhere? I don't know if libvirt has a way >>>> of tracking >>>> these kinds of discoveries, I'd be happy to open a ticket somwhere >>>> and put >>>> it in the libvirt backlog. >>>> >>> >>> Sure, you can file an issue on gitlab: >>> >>> https://gitlab.com/libvirt/libvirt/-/issues/new >>> >>> but I'll try to work on and post a quick fix anyway so that it does not >>> block my already late review of your v3. >>> >> >> Sorry, I completely forgot to let you know that the fix is already in >> the latest release, last commit of the series in master is 6f0974ca32ce. >> Would you mind rebasing your patches on top of current master to reflect >> the changes? >> > Sorry for the late reply. OK, awesome. Will rebase again. Thanks Martin. > > - Michael > >