Re: [libvirt] [PATCH 3/5] conf, schema, docs: Add support for TSEG size setting

On Wed, May 30, 2018 at 12:00:26PM -0400, John Ferlan wrote: Rather than promising some value, I adjusted it so that it is no longer false, no matter what the max is there. You can enable/disable 3-way merges if you do (not) like them. Yeah, happened to me as well, I should've resent this, but I forgot about the merge issue and I also wanted to show that this was posted way before the freeze. Anyway, it's pointless to force it now, I'll leave it for later (meaning "after the release"). Anyway, I keep my branches updated (every now and then) on my github repo [1], so if you want to check that, you always can. [1] https://github.com/nertpinx/libvirt It's kind of a different story. Think of this as a memory size. You cannot determine the "right" amount of memory the VM should have. You can try to boot with X and double it until the OS installation succeeds. And hope you won't need to change it later. This is about tunables. It might change the performance/latency of QEMU slightly, but that's about it. Similarly here, it allows setting something that can be (at least slightly) abstracted and in the worst case the performance will be slightly hindered. Contrast this with TSEG which, in case it is set incorrectly, will prevent the machine from booting at all. If we go to the extreme, not only can you easily try to find out the right amount to set for a particular machine, but you can even do that programmatically since when OVMF fails due to small extended TSEG size it will reboot very fast. And you can get that in form of events. When I tried it now it even looks like you get rtc-change event when the domain doesn't reboot immediately due to small TSEG size. I will not put it in the docs because I will not guarantee that this is the right way to go, but this is how events look for default TSEG size for a guest that needs a lot more (it has 240 possible vCPUs and 256 TiB of maximum memory, but because it starts with only 1 vCPU and 1GiB memory I can try it out easily on my machine: virsh # event --domain nixos --all --loop --timestamp 2018-05-31 09:42:21.060+0000: event 'lifecycle' for domain nixos: Resumed Unpaused 2018-05-31 09:42:21.066+0000: event 'lifecycle' for domain nixos: Started Booted 2018-05-31 09:42:21.514+0000: event 'reboot' for domain nixos 2018-05-31 09:42:21.964+0000: event 'reboot' for domain nixos 2018-05-31 09:42:22.414+0000: event 'reboot' for domain nixos 2018-05-31 09:42:22.868+0000: event 'reboot' for domain nixos 2018-05-31 09:42:23.325+0000: event 'reboot' for domain nixos 2018-05-31 09:42:23.778+0000: event 'reboot' for domain nixos 2018-05-31 09:42:24.230+0000: event 'reboot' for domain nixos 2018-05-31 09:42:24.681+0000: event 'reboot' for domain nixos ... you get the point. And this is how it looks when I start it with increased size: virsh # event --domain nixos --all --loop --timestamp 2018-05-31 09:43:24.578+0000: event 'lifecycle' for domain nixos: Resumed Unpaused 2018-05-31 09:43:24.584+0000: event 'lifecycle' for domain nixos: Started Booted 2018-05-31 09:43:31.808+0000: event 'rtc-change' for domain nixos: 0 2018-05-31 09:43:32.808+0000: event 'rtc-change' for domain nixos: 0 The reasons for this not being done automatically are (from the top of my head): - The above is just something I figured out myself, but it's not the recommended way written anywhere. Maybe I'm wrong and it doesn't really work, but it still can be done manually. - You cannot change it however you would like automatically, it is part of the guest ABI and we are striving for keeping that stable. - Trying to figure this out by 1 MiB increments might take some time, but increasing it faster might be wasteful. Basically there is no one-size-fits-all value, no easy way to do it automatically (maybe what I tried), but very good explanation how to do that manually and very easy way to do that. Also, from the SW POV, it doesn't even depend on the guest OS, just on the loader/bios so if you have two same domains (like a template in OpenStack for example) you try it out once and then you have the value that just works and will continue working until you change something for the domain. And what it depends on is clearly written in the documentation. It is not. They are rejected because either a) there is no documentation how to properly check if the value is the right value when doing trial-end-error (this is not the case here since you can see if the machine boots or not) or b) the values being set are too specific instead of being abstracted -- setting value in KiB between 0 and the size of a disk instead of "max_performance" or "min_latency" (this is not the case here, the documentation explains what the size is and why it is not about few guessable values). Basically we are NACKing simple pass-through values without understanding them and adding some documentation for them. For example stuff for which we have documentation along the lines of: "Element asdf can be used to set the asdf of the domain." Let me know what relevant information from the bz you are missing in the documentation and I'll gladly add it. So? How much more exact would you wanted to be in terms of sizing? If it could be any more exact we wouldn't need the tunable at all. Please don't compare it to other tunables that we didn't want exposed just because it "sounds similar". I hear lot of people just put stuff like this into "unknown knobs" box and they treat it the same. But there are differences and it's not all I wasn't ever against the R-b, but I guess I'm missing the point. You disagree with me on the change made here, but then I get a R-b? :) And then I go further down and read that the R-b has actually no value at all and I should wait for another one :D Maybe I'm overthinking this, but it didn't used to happen back when we used ACKs :)