[SOLVED] Hyper-Threading vs No Hyper-Threading; Fixed vs Variable Memory

[ieronymous]

"None". This gives max reliability, saves Ram by not double storing data in Ram and does not lie to the guest os.

My storage is ZFS. It has its own optimization for writing async data.

Mine as well. I was under the impression that write back was the safe option for data integrity and it was a specific option for win vms. For llinux it was set to off. Observed this in many configuration videos.

Can you set it to off afterwards? I guess yes but never mind to double checking things.

 

[UdoB]

Can you set it to off afterwards?

Sure.

You'll notice this modified setting will be listed in a second line in yellow/orange color. This means the VM has to be shutdown/restarted (from the host, not from within the guest) to get activated.

 

[ieronymous]

You'll notice this modified setting will be listed in a second line in yellow/orange color. This means the VM has to be shutdown/restarted (from the host, not from within the guest) to get activated.

Why? What is the difference between 2 shutdown modes?
Yet, since I'm using this option as a good practice (mean the write back). Just <<none>> and <<This gives max reliability, saves Ram by not double storing data in Ram and does not lie to the guest os.>> doesn t glue together.
Care to elaborate since I don't get it.

My documentation always was :
Cache: Notifies host when guest's read/write operations are finished.
No Cache for Linux / Write back for Windows

PS I m also into this info https://pve.proxmox.com/wiki/Performance_Tweaks which may seem to be on your way of setting this thing up. Not quite sure though.

 

[UdoB]

Why? What is the difference between 2 shutdown modes?

If you reboot from inside the guest then the KVM process on the host does not stop. But this is required to change the configuration.

<<This gives max reliability, saves Ram by not double storing data in Ram and does not lie to the guest os.>> doesn t glue together.

Which part?
"Reliability" in my sense comes from actually writing data to persistent storage and using ZFS for checksumming.
"Saving Ram" comes from: adding an additional (write-) cache means to store the data meant to be written to disk in volatile Ram - at least for a (very) short amount of time.
"Lying" come from stating to the guest OS that data has been written while it actually is not.

Each aspect may be tolerable as it usually works fine.

 

[ieronymous]

Which part?

The part that cache = none would give just max performance .

"Reliability" in my sense comes from actually writing data to persistent storage and using ZFS for checksumming.

So with cache=none the OS's cache communicated not with the host layer but the zfs file system directly and that gives reliability?

"Lying" come from stating to the guest OS that data has been written while it actually is not.

That is the part I thought it was the opposite. I was <<wrongly>> aware that that is why you choose cache=writeback in order for a check to be done first from the host if the data is committed and give the order for the next chunk of date to be written afterwards.....etc

PS: I am insist on asking of another way since closing VM from the Host most of the times (at least for me) needs afterwards chkdsk /f /r and sfc scannow where it finds corruption and corrects it. If I run the same commands before the <<forceful shutdown>> then no corruption error.
So, if I shutdown from guest, change the parameter to the desired value and reboot the host afterwards?

 

[UdoB]

The part that cache = none would give just max performance .

Where did I say that? I wrote "This gives max reliability".

So with cache=none the OS's cache communicated not with the host layer but the zfs file system directly and that gives reliability?

Basically yes. One man-in-the-middle less as otherwise.

So, if I shutdown from guest, change the parameter to the desired value and reboot the host afterwards?

Stop, no! We are talking about changing the cache-settings of a guest, right? No need to reboot the host!

So shutdown a guest from inside that same guest will allow to trigger the activation of configuration changes; reboot from inside will not work. The point is that the kvm-process on the host has to come to an end. Only then (some) configuration will/can get activated.

 

[ieronymous]

Where did I say that? I wrote "This gives max reliability".

That's what I thought, not what you meant.

We are talking about changing the cache-settings of a guest, right?

yes

No need to reboot the host!

... because only then the kvm service will restart too to take the changes. Why you were so cautions of a restart? It s not that bad.
I m doing it once in a few weeks for updates of Proxmox and stuff.