@tteck i understand what you say.
I really appreciate all your hard work for all your scripts, but 3. Resize the HDD (Single HDD) works perfect and never had an issue, i sold many units (348) doing this way never had one come back with an issue… for now a year.
myself running 3 t630 systems and 5 big servers with all kind of vm’s so i disagree with you.
I did setup them all like that…
otherwise i would not make this tutorial and post it even here.
Even my old tutorial has been proven and used by many Youtubers.
I did some testing on the old proxmox first and back than i released a small tutorial on reddit a long while ago…
its even featured in the video of (network chuck) just seen it whil searching on my line.
look here at the proxmox forum, there are so many forums even on reddit discussing this, not even 1 person that says better don’t use it.
my 3. Resize the HDD (Single HDD) is just safe to use.
people can research the code and look it up, even on the proxmox forums they talk about it…
In that case, we appear to have differing opinions. Could you please clarify your reasons for removing local-lvm, or are you in a similar position to Network Chuck, lacking insight? My concern lies in ensuring that users receive accurate information and are not led astray.
About chuck was just an example (yes that guy i don’t even like him), there are more YouTubers doing this.
i just did a seach on it and came across him and a lot of reddit posts and proxmox forum posts.
check the link from 2017 in that forum there is an other link.
believe me, i sold many many systems never had any issue, and ofcourse we have different opinions and thats ok.
the reason mainly (reclaiming storage)
Changing Storage Configurations:
Reclaiming Storage:
Simplifying Configuration:
i added a warning on step 3 to let people first do some extra research.
Performance: Local-LVM storage can offer better performance for I/O-intensive workloads due to its direct block-level access. This can be important for applications with high storage demands.
Isolation: Local-LVM allows you to create logical volumes for each VM or container, providing isolation and preventing one VM’s or container’s storage from impacting others.
Reduced Fragmentation: By using LVM, you can reduce file system fragmentation, which can lead to improved performance and storage efficiency.
Considerations for Removing Local-LVM Storage:
Usage Profile: If you’re running less I/O-intensive workloads or don’t require the specific benefits of Local-LVM storage, you may not notice a significant performance difference.
Management: Removing Local-LVM storage simplifies your storage management, which can be advantageous for environments where complexity is a concern. This might be the case for smaller or less complex setups.
Resource Reallocation: If you’re removing Local-LVM storage to free up resources for other storage solutions or for a different configuration, ensure that the changes align with your current and future needs.
In the end, the choice to use or remove Local-LVM storage depends on your use case and your performance and management requirements. If you have been successfully operating without it and don’t require the performance benefits, it might be a valid decision to remove it.
If you decide to remove Local-LVM storage, it’s crucial to have a proper backup of any VMs or containers hosted on that storage
You are not reclaiming storage, you’re just moving it to standard file-based storage, which I explained is not the best way to go.
I provided crystal-clear justifications for retaining local-LVM, so what’s the true rationale behind getting rid of it? Just because Network Chuck said so or because I stumbled upon it on the internet?
yes i am reclaiming storage.
by running the full code after like its written in step 3
i mean look up the proxmox forums/ reddit, people are talking about it how to reclaim extra space…
Reclaiming Storage: If you’re running low on storage space and don’t need the “local-lvm” storage, removing it can free up space for other purposes.
example they talk about resizing/reclaiming storage that’s how the rest of the code of step 3 works.
like it says on my post here that’s the correct information.
I think what 𝙩𝙩𝙚𝙘𝙠𝙨𝙩𝙚𝙧 is politely making you aware of is that you are following a treacherous path. The reason why you have not hit the wall yet is because your user base are most likely underutilising their systems, plus your systems are not battle tested for 5-10 years, to see why 𝙩𝙩𝙚𝙘𝙠𝙨𝙩𝙚𝙧 is advising you to reconsider your future actions.
You can argue your case all you want, but at the end of the day you are not following the right path. Just a friendly advice: there are good reasons why certain technologies exist and are highly recommended.
i agree, but the tutorial is from 2017 and we are in 2023 so yes its tested.
like i said before, i won’t even post the tutorial here if i was not even sure about it.
so i added a note here on step 3, and people can look it up.
Decided to delete the tutorial as this is getting nuts. I understand different opinions but facts are facts, i sold many systems the last years and never 1 system got returned (of this issue) as i maintain them when there are problems.
who ever is interested in the tutorial i will dm it.
Interesting, ‘constructive’ and informative conversation. Thanks. I too fell foul of Network Chucks advice (specifically here: https://youtu.be/_u8qTN3cCnQ?t=886), and will rebuild my Proxmox installation accordingly, just to be on the safe side. (its not too late )
Incidentally, in relation to my question about USB over IP, I think this solves it. There are a ton of very helpful people out there, kudos to them
You can use zigbee2mqtt for remote zigbee dongle setups. It abstracts the entire zigbee stack instead of just the USB controller.
Highly recommended since it’s very reliable and performant.
Zwavejs is also available as the zwave equivalent.
You’ll need a SBC like rpi4 (older rpis work too, but they may need to be run bare metal instead of dockerized which can be a huge pain), but this is a requirement that exists with USB over IP as well.
I’ve migrated to both zigbee2mqtt and zwavejs since last year and I’m very happy with the results.
This picture is becoming more clear to me now. I am trying to achieve a really solid Proxmox HA solution, spread across One mini PC, and two Pi4s. Learning a lot, quite enjoying the ride!
For my Electrolama ZZH Dongle, I originally thought some detached pure USB->IP transport service was the only way to achieve this (looks like a solution exists, but really isn’t mature enough for Prod).
Thanks rice12, your approach makes sense. Do you run your zigbee2mqtt install in a dedicated docker container on its own Pi4, or something else?
hey malosaa, i would be interested in reading your guide as well as im looking at choosing between LCX and regular VM HA setup for my future house, thanks a lot mate
My two cents to HA Home assistant. At the moment I’m gradually moving to this concept implementation.
There are mini pc with two m.2 or. M.2 and sata interfaces on the second hand market. This would allow to install proxmox on one drive and keep second drive for CEPH.A cluster to three nodes can provide high availability for VM and CEPH will take care of data. VM seems a bit better solution in terms of long term maintenance. Performance penalty for VM is negligible. Proxmox allows memory ballooning by specifying min and max values for ram usage. Ballooning allows return of unused memory to the host.
Running a cluster of three Proxmox nodes as a cluster would provide VM HA and running at least two zig star devices would provide zigbee redundancy. More zigstar devices would provide a better covert for bigger estates.
In the end there is a redundancy for bot VM and zigbee layers. 1gbit network is not stellar for high computing but good enough for HA home assistant and all services around.
)