As per request I added Alpine, 3.18 also added Devuan Daedalus ( Debian 12 )
Was a bit more work, since microLXC never saved the installed OS, it wasn't necessary after deployment.
However to spawn the correct shell when you use _Console its now needed for Alpine since its uses ash instead of bash.
Stock update / Maintenance
We have a bunch of nodes that still have spare capacity however are limited due to the current configuration.
I plan to reboot the following nodes to increase capacity.
Melbourne
Johannesburg
Auckland
Valdivia
At around 19:00 UTC Wednesday next week.
Expect a few minutes of downtime while the nodes will be rebooted.
Regarding Japan, I am still waiting for IPv6.
However, I will patch microLXC for NAT only, when the IPv6 prefix will become available it should be possible to enable it without a reboot and add a button to the Panel, so you can let microLXC assign you a /64 prefix.
@Neoon said: Stock update / Maintenance
We have a bunch of nodes that still have spare capacity however are limited due to the current configuration.
I plan to reboot the following nodes to increase capacity.
Melbourne
Johannesburg
Auckland
Valdivia
At around 19:00 UTC Wednesday next week.
Expect a few minutes of downtime while the nodes will be rebooted.
@Neoon said: restock will happen later though, no ETA.
I have to rest my left hand for 2 weeks.
I also have to check how much I can restock and take a look at the current usage, maybe apply some rules.
No problem, and thanks for letting me/us know, appreciate it - I won't F5 anymore. :-)
Health should always come first, even though we sometimes forget the importance.
What happened to your left hand, will everything be ok?
( Hand injuries can really suck and can take very long to recover )
ps: Would you suggest I apply so long and select an EU location to 'get onto the system' so long (hopefully) and then later change, or should I rather not and just wait until the restocks before I apply at all?
@Neoon said: restock will happen later though, no ETA.
I have to rest my left hand for 2 weeks.
I also have to check how much I can restock and take a look at the current usage, maybe apply some rules.
No problem, and thanks for letting me/us know, appreciate it - I won't F5 anymore. :-)
Health should always come first, even though we sometimes forget the importance.
What happened to your left hand, will everything be ok?
( Hand injuries can really suck and can take very long to recover )
No idea, should be fine though.
ps: Would you suggest I apply so long and select an EU location to 'get onto the system' so long (hopefully) and then later change, or should I rather not and just wait until the restocks before I apply at all?
NAT only is done and tested, however I still going to write some additional tests for the buildserver.
I didn't had time yet adding the requested os images or smaller packages.
Linux will run happily with only 8 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on. However, having more memory is almost as important as having a faster processor. Sixteen megabytes is just enough for personal use; 32 MB or more may be needed if you are expecting a heavy user load on the system.
We accept Karma donations for the last flan. 🍮 affbrr
Linux will run happily with only 8 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on. However, having more memory is almost as important as having a faster processor. Sixteen megabytes is just enough for personal use; 32 MB or more may be needed if you are expecting a heavy user load on the system.
A few things, before I restock.
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
I prefer this instead of a hard limit per node.
Second thing, regarding bigger Packages.
Currently it works like this, you can grab any Package, as long the Node has the Memory available.
However, if the Node is getting low on Memory, it doesn't make much sense, especially on bigger packages.
Lets say the demand on one Node is high, it has roughly 1GB of Memory left to allocate, it would still offer you the 512MB Packages.
This changes by now, in this case, the highest Package that would be available is the 256MB Package.
If the available memory gets lower, it would offer you the next smaller package respectively, downwards to 64MB.
In the case its possible to get the Node upgraded, I will do so.
@Neoon said:
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
Suppose I consider to downgrade but I need to test whether the application would actually work in the smaller package before deleting the larger package:
Start with container A with 256MB.
Create container B with 128MB, counted as 256MB.
I do my test in container B and find that it works in the smaller package.
Delete container A.
Does container B revert to 128MB cost at this point?
We accept Karma donations for the last flan. 🍮 affbrr
@Neoon said:
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
Suppose I consider to downgrade but I need to test whether the application would actually work in the smaller package before deleting the larger package:
Start with container A with 256MB.
Create container B with 128MB, counted as 256MB.
I do my test in container B and find that it works in the smaller package.
Delete container A.
Does container B revert to 128MB cost at this point?
Yeah, what Node are you talking about?
I might consider applying it only on Nodes with less than 8GB of memory.
@Neoon said:
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
Suppose I consider to downgrade but I need to test whether the application would actually work in the smaller package before deleting the larger package:
Start with container A with 256MB.
Create container B with 128MB, counted as 256MB.
I do my test in container B and find that it works in the smaller package.
Delete container A.
Does container B revert to 128MB cost at this point?
Yeah, what Node are you talking about?
I might consider applying it only on Nodes with less than 8GB of memory.
I want downgrade in Singapore, as I have 256MB but the application might work on 128MB.
However, this is not about specific node, but the general application logic.
I think the most fair way would be:
Largest container costs 1x.
Second largest container costs 2x.
Third largest container costs 3x.
…
… regardless of creation and deletion order.
The costs are reevaluated upon creating or deleting a container.
We accept Karma donations for the last flan. 🍮 affbrr
@Neoon said:
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
Suppose I consider to downgrade but I need to test whether the application would actually work in the smaller package before deleting the larger package:
Start with container A with 256MB.
Create container B with 128MB, counted as 256MB.
I do my test in container B and find that it works in the smaller package.
Delete container A.
Does container B revert to 128MB cost at this point?
Yeah, what Node are you talking about?
I might consider applying it only on Nodes with less than 8GB of memory.
I want downgrade in Singapore, as I have 256MB but the application might work on 128MB.
However, this is not about specific node, but the general application logic.
I think the most fair way would be:
Singapore isn't a small node, hence the rule would not apply.
If I exclude nodes bigger than 8GB, Singapore, Japan... would not be on that list.
However, all other nodes in APAC, Africa, South Africa would be.
Nodes in Europe would be neither on that list.
Largest container costs 1x.
Second largest container costs 2x.
Third largest container costs 3x.
…
… regardless of creation and deletion order.
The costs are reevaluated upon creating or deleting a container.
The point is, small nodes, have not as much resources.
So you want people not to deploy their allocation mostly there right.
Hence the cost increase if you go for a second container.
So for the future, no more limit qty of how many container we can create?
Nobody said that, you still have a limit.
The Limit works different though.
Second, all locations seems oos.
Yes because we had an increase of roughly 100% and I am currently reworking the memory calculation
Third, what does a bar showing 768MB | 1280MB on top of dashboard menu mean?
Your memory you already used and what you have available.
In exchange of a backlink I did increase the quota to 2, so you could deploy a second container.
Currently this does reflect for some people as 2048MB.
However, given you can deploy a second container anyway, this is likely to be reset to 1024MB.
Oradea is now available, Native IPv6 however only a /70 and depending on version and distro, manual configuration might be required.
In future we should get a bigger IPv6 Prefix, so it will work out of the box.
The concept has intrigued me, but I have no experience with it yet. If I apply for a spot in Oradea, can I still apply for a new one or a replacement when another location becomes available? I already have a NAT VPS with, well, eh, NATVPS, in Orastie.
With 200km it's not directly around the corner from Oradea, but still in Romania as well. Might stock become available in any non-Eurasia datacenter?
@wankel said:
I just found out my stats clear me for access!
Wohoo :-)
The concept has intrigued me, but I have no experience with it yet. If I apply for a spot in Oradea, can I still apply for a new one or a replacement when another location becomes available? I already have a NAT VPS with, well, eh, NATVPS, in Orastie.
With 200km it's not directly around the corner from Oradea, but still in Romania as well. Might stock become available in any non-Eurasia datacenter?
You can delete and recreate them as you want.
I added some Stock, will Restock later again what I can.
Good news everyone, Romania has been upgraded to a /64 prefix per container.
The old prefix will continue to work, however there is currently no button to apply the new network configuration so you essentially stuck on the old prefix until you terminate and deploy again. Reinstall won't change or modify your current allocation.
Or you wait until the Feature is available, possibly this week.
I restocked some Locations, even if the Node shows Available it can be that its suddenly out of stock due to running out of disk.
I modified the system to track storage usage too, because of the increased density, it doesn't reflect that yet.
Groningen needs a maintenance before it can get any restocks, possibly in the next weeks.
@Neoon said:
I modified the system to track storage usage too, because of the increased density, it doesn't reflect that yet.
Storage oversubscription will end very badly.
A few users decide to fill their partition => ENOSPC: no space left on device for everyone.
Nah, microLXC currently does only allocate disk space that physical available.
Before the patch Johannesburg was slightly overallocated, but the stock system takes care of that after the Patch.
Hence Melbourne and Johannesburg are out of stock or going in and out of stock really quickly, despite having enough memory available but storage is the issue.
I already asked for Melbourne to get a bigger disk allocation, will see.
Memory is slightly overallocated < 10% but only on bigger nodes, so no issue there.
Bandwidth wise, 200% - 300% on some nodes, still within limits and if we should hit the bandwidth limit one day, I just ask for an upgrade.
Since the Traffic allocations have been upgraded in SG and JP, kudos to @Abdullah / https://webhorizon.net
All Packages in JP have been upgraded by +50GB.
SG has only one regional Package, mediumSG which also has been upgraded by +50GB.
If someone really needs 250GB in SG, I can create a regional SG package with 250GB allocation, for 256MB and smoler.
Depending on traffic usage, it might be bumped to 300GB, but will see.
@ElonBezos said:
i still can't ssh to my tyo & nz untill now, is it supposed to be like that? but i confirm still able to connect it via _shell
You have to let me know if you have any issues, but I don't see anything wrong there besides your SSH seems not to be even listening on NZ. Looks more like a issue related to SSH for some reason.
Tokyo no idea, we got 2 Nodes, you have to be more precise.
Comments
It was to test whether the wrong assigment was exactly repeatable, or the result of a transient glitch. Damn you, cosmic rays.
Happy customer at AlexHost, AxusHost, Bakker-IT, Host-C, Ionos, Veesp + NanoKVM ftw.
bcfd-9be7-eb95-0159
don't ask why
youtube.com/watch?v=k1BneeJTDcU
As per request I added Alpine, 3.18 also added Devuan Daedalus ( Debian 12 )
Was a bit more work, since microLXC never saved the installed OS, it wasn't necessary after deployment.
However to spawn the correct shell when you use _Console its now needed for Alpine since its uses ash instead of bash.
Free NAT KVM | Free NAT LXC
Stock update / Maintenance
We have a bunch of nodes that still have spare capacity however are limited due to the current configuration.
I plan to reboot the following nodes to increase capacity.
At around 19:00 UTC Wednesday next week.
Expect a few minutes of downtime while the nodes will be rebooted.
Free NAT KVM | Free NAT LXC
Regarding Japan, I am still waiting for IPv6.
However, I will patch microLXC for NAT only, when the IPv6 prefix will become available it should be possible to enable it without a reboot and add a button to the Panel, so you can let microLXC assign you a /64 prefix.
Free NAT KVM | Free NAT LXC
Done, restock will happen later though.
Free NAT KVM | Free NAT LXC
I've maybe been F5'ing a bit too anxiously the last half hour, to try and not miss ZA/Jhb again
restock will happen later though, no ETA.
I have to rest my left hand for 2 weeks.
I also have to check how much I can restock and take a look at the current usage, maybe apply some rules.
Free NAT KVM | Free NAT LXC
No problem, and thanks for letting me/us know, appreciate it - I won't F5 anymore. :-)
Health should always come first, even though we sometimes forget the importance.
What happened to your left hand, will everything be ok?
( Hand injuries can really suck and can take very long to recover )
ps: Would you suggest I apply so long and select an EU location to 'get onto the system' so long (hopefully) and then later change, or should I rather not and just wait until the restocks before I apply at all?
Is the left hand doing what @ehab thinks it's doing?
We accept Karma donations for the last flan. 🍮 affbrr
No idea what @ehab is thinking.
No idea, should be fine though.
Does not really make a difference.
Free NAT KVM | Free NAT LXC
NAT only is done and tested, however I still going to write some additional tests for the buildserver.
I didn't had time yet adding the requested os images or smaller packages.
Free NAT KVM | Free NAT LXC
JP2 is available now, no IPv6 yet only NAT, IPv6 will be available once I got the Prefix.
Thanks to @Abdullah / https://webhorizon.net/
Currently 3 Packages are available.
If you have any suggestions, lemme know.
Free NAT KVM | Free NAT LXC
64 MB package please.
Why?
Yeah, I have to add a whitelist feature for operating systems that work on low memory systems before I can just add a 64MB Package.
Free NAT KVM | Free NAT LXC
32 MB package please.
It's enough for a heavy user load.
Linux will run happily with only 8 MB of RAM, including all of the bells and whistles such as the X Window System, Emacs, and so on. However, having more memory is almost as important as having a faster processor. Sixteen megabytes is just enough for personal use; 32 MB or more may be needed if you are expecting a heavy user load on the system.
We accept Karma donations for the last flan. 🍮 affbrr
Thats even better
Why?
As per Request, I added a 64MB Package.
Currently Alpine is the only whitelisted OS, others will be added.
Restock is next on the list, also have to add the new Node from @host_c
Free NAT KVM | Free NAT LXC
A few things, before I restock.
The Resource allocation now works a bit differently, if you deploy more than 1 Container on the same Node, the cost will increase.
Given by the amount of containers you have/want to deploy.
For example you already have 1 Container on the same Node and you want to deploy another one.
The cost (memory allocation) is doubled, for the 3rd its tripled and so on.
I prefer this instead of a hard limit per node.
Second thing, regarding bigger Packages.
Currently it works like this, you can grab any Package, as long the Node has the Memory available.
However, if the Node is getting low on Memory, it doesn't make much sense, especially on bigger packages.
Lets say the demand on one Node is high, it has roughly 1GB of Memory left to allocate, it would still offer you the 512MB Packages.
This changes by now, in this case, the highest Package that would be available is the 256MB Package.
If the available memory gets lower, it would offer you the next smaller package respectively, downwards to 64MB.
In the case its possible to get the Node upgraded, I will do so.
Feedback?
Free NAT KVM | Free NAT LXC
Suppose I consider to downgrade but I need to test whether the application would actually work in the smaller package before deleting the larger package:
Does container B revert to 128MB cost at this point?
We accept Karma donations for the last flan. 🍮 affbrr
Yeah, what Node are you talking about?
I might consider applying it only on Nodes with less than 8GB of memory.
Free NAT KVM | Free NAT LXC
I want downgrade in Singapore, as I have 256MB but the application might work on 128MB.
However, this is not about specific node, but the general application logic.
I think the most fair way would be:
… regardless of creation and deletion order.
The costs are reevaluated upon creating or deleting a container.
We accept Karma donations for the last flan. 🍮 affbrr
Singapore isn't a small node, hence the rule would not apply.
If I exclude nodes bigger than 8GB, Singapore, Japan... would not be on that list.
However, all other nodes in APAC, Africa, South Africa would be.
Nodes in Europe would be neither on that list.
The point is, small nodes, have not as much resources.
So you want people not to deploy their allocation mostly there right.
Hence the cost increase if you go for a second container.
Free NAT KVM | Free NAT LXC
… or just disallow two containers in the same place, but enable upgrade/downgrade button.
We accept Karma donations for the last flan. 🍮 affbrr
I am still against hard limits, would be easily added though.
Upgrade/Downgrade is a nice Feature surely, however has its limitations too.
For example does not work / risky with KVM, at least downgrades.
At some point I will add it, but not now.
Free NAT KVM | Free NAT LXC
Change of plans, since I got some feedback.
The cost increase will depend on the Node size.
If the Node has more than 8GB of memory, 2 containers will be calculated as before.
The 3rd, is going to cost double.
If the Node has less than 8GB of memory, 1 container will be calculated as before.
The second container, is going to cost double and so on.
This does not take the size of the Package into account.
If the Node already is low on memory, even a 64MB Package would count.
Since I probably even add a 32MB Package and I don't want to cut the traffic by half, again.
I won't exclude anything smaller than 128MB.
On bigger nodes, this rule might have an exception in the future, if traffic isn't a problem.
Free NAT KVM | Free NAT LXC
OK now my head hurts
Happy customer at AlexHost, AxusHost, Bakker-IT, Host-C, Ionos, Veesp + NanoKVM ftw.
@Neoon
So for the future, no more limit qty of how many container we can create?
Second, all locations seems oos.
Third, what does a bar showing 768MB | 1280MB on top of dashboard menu mean?
https://microlxc.net/
Means you can deploy several more VPS in terms of memory.
MicroLXC is lovable.
Nobody said that, you still have a limit.
The Limit works different though.
Yes because we had an increase of roughly 100% and I am currently reworking the memory calculation
Your memory you already used and what you have available.
In exchange of a backlink I did increase the quota to 2, so you could deploy a second container.
Currently this does reflect for some people as 2048MB.
However, given you can deploy a second container anyway, this is likely to be reset to 1024MB.
Free NAT KVM | Free NAT LXC
Oradea is now available, Native IPv6 however only a /70 and depending on version and distro, manual configuration might be required.
In future we should get a bigger IPv6 Prefix, so it will work out of the box.
Thanks to @host_c / https://www.host-c.com
Currently 4 Packages are available.
The new memory calculation is also live, feel free to check it.
Free NAT KVM | Free NAT LXC
I just found out my stats clear me for access!
Wohoo :-)
The concept has intrigued me, but I have no experience with it yet. If I apply for a spot in Oradea, can I still apply for a new one or a replacement when another location becomes available? I already have a NAT VPS with, well, eh, NATVPS, in Orastie.
With 200km it's not directly around the corner from Oradea, but still in Romania as well. Might stock become available in any non-Eurasia datacenter?
You can delete and recreate them as you want.
I added some Stock, will Restock later again what I can.
Free NAT KVM | Free NAT LXC
fd59-9f49-45ac-a0e0
very appreciative, many thanks! :-)
5cdf-3b14-37e8-4d95
Looking forward!
1be0-ab4c-b5b9-d13e
Any chance for resource modification?
https://microlxc.net/
No, The System is fully automated, there is no Support of any kind to upgrade or modify packages.
Free NAT KVM | Free NAT LXC
312e-5479-26bd-dbc4
Understood!
https://microlxc.net/
f4d7-6a4e-bc11-7391
Good news everyone, Romania has been upgraded to a /64 prefix per container.
The old prefix will continue to work, however there is currently no button to apply the new network configuration so you essentially stuck on the old prefix until you terminate and deploy again. Reinstall won't change or modify your current allocation.
Or you wait until the Feature is available, possibly this week.
Big thanks to @host_c
Free NAT KVM | Free NAT LXC
I restocked some Locations, even if the Node shows Available it can be that its suddenly out of stock due to running out of disk.
I modified the system to track storage usage too, because of the increased density, it doesn't reflect that yet.
Groningen needs a maintenance before it can get any restocks, possibly in the next weeks.
Free NAT KVM | Free NAT LXC
Storage oversubscription will end very badly.
A few users decide to fill their partition => ENOSPC: no space left on device for everyone.
We accept Karma donations for the last flan. 🍮 affbrr
Nah, microLXC currently does only allocate disk space that physical available.
Before the patch Johannesburg was slightly overallocated, but the stock system takes care of that after the Patch.
Hence Melbourne and Johannesburg are out of stock or going in and out of stock really quickly, despite having enough memory available but storage is the issue.
I already asked for Melbourne to get a bigger disk allocation, will see.
Memory is slightly overallocated < 10% but only on bigger nodes, so no issue there.
Bandwidth wise, 200% - 300% on some nodes, still within limits and if we should hit the bandwidth limit one day, I just ask for an upgrade.
Free NAT KVM | Free NAT LXC
Since the Traffic allocations have been upgraded in SG and JP, kudos to @Abdullah / https://webhorizon.net
All Packages in JP have been upgraded by +50GB.
SG has only one regional Package, mediumSG which also has been upgraded by +50GB.
If someone really needs 250GB in SG, I can create a regional SG package with 250GB allocation, for 256MB and smoler.
Depending on traffic usage, it might be bumped to 300GB, but will see.
Free NAT KVM | Free NAT LXC
Viva La MicroLXC
i still can't ssh to my tyo & nz untill now, is it supposed to be like that? but i confirm still able to connect it via _shell
You have to let me know if you have any issues, but I don't see anything wrong there besides your SSH seems not to be even listening on NZ. Looks more like a issue related to SSH for some reason.
Tokyo no idea, we got 2 Nodes, you have to be more precise.
Free NAT KVM | Free NAT LXC
i'll look further in to this
it said tyo only, the other tyo equinix seems fine for me
anyway unable to ssh is not a big deal for me since i can access them from the portal