New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Very nice update sir! Congratulations! Lovely service!
where dealz pls?
Posted it several times but seems to be removed I’ll try again m8
.
@onidel recently introduced AMD SEV to their Amsterdam location.
I decided to make some benchmarks to check how it influences performance.
Out of the box YABS without SEV or FDE using Debian 12 template:
YABS from custom Debian install with FDE (LUKS2) enabled:
To make sure SEV is enabled and working, you can either check
dmesg:or use
cpuid:YABS from custom Debian install with SEV and FDE (LUKS2) enabled:
There isn't any major difference between SEV and non SEV GB6 score. I expected it to be at least a bit lower than unencrypted.
The biggest difference we see is in
fiobenchmark. Enabling LUKS2 encryption reduced disk IOPS by at least 2x. We also see slightly lowerfioscore with SEV enabled.The
fioscores were vastly improved after I applied the steps from long-cat blog (increasing sector size to 4KB, disabling work queues in/etc/crypttaband setting key size to 256 bits). Now IOPS are only slightly behind what they were using an unencrypted drive.fioscores for FDE (LUKS 4KB sectors) without SEV:fioscores for FDE (LUKS 4KB sectors) with SEV:Those are great results! I expected it to perform much worse, but SEV and non-SEV results are indistinguishable in most benchmarks (fio being the only exception).
Onidel did a great job making sure the SEV option is easily accessible within their panel and can be enabled at any time.
Hopefully more providers will decide to support SEV soon
A few additional benchmarks I ran hoping SEV will fall behind in some workload. (it didn't
)
without SEV:
cryptsetup
p7zip
zstd
with SEV:
cryptsetup
p7zip
zstd
Great benchmarks @oloke - really love the detailed work!
One caveat with supporting AMD SEV is the loss of live migration capability for SEV-enabled VMs. At Onidel, we regularly perform live migrations to apply updates, carry out maintenance, and rebalance workloads across nodes - all without affecting VM uptime. This helps us maintain consistent performance and reliability across the platform.
With SEV-enabled VMs, however, our process needs to adapt. Specifically, we will now provide advance notice for planned maintenance, during which SEV-enabled VMs will need to be temporarily shut down. The downtime is typically brief - thanks to our distributed storage cluster, migrations usually take only a few seconds to a few minutes.
Despite this limitation, we believe SEV is a valuable option for customers seeking greater privacy and data protection. We are also actively working on supporting SEV-ES and SEV-SNP, which will involve additional work such as rebuilding the EFI firmware (-ES and -SNP do not work with Secure Boot enabled).
This is great, thanks @oloke , are you using clevis/tang to auto unlock boot ?
and how to get sev-enable node @onidel ?
All nodes in Amsterdam support SEV. If you have a VM in Amsterdam, you can enable SEV from our control panel.
Sydney, Singapore and New York (launching soon) will also support SEV. ETA in 2-3 weeks.
any promo ?
I was using clevis binded to vTPM.
Preferably, bind it to a Tang server that you fully control since vTPM could be compromised.
Using systemd-cryptenroll ?
Using clevis but systemd-cryptenroll should work too
https://community.frame.work/t/guide-setup-tpm2-autodecrypt/39005#configuration-explaination-2
Seeing from short searching about vtpm, any particular reason not using Clevis server? vtpm setup looks significantly harder.
I don't think it's much harder. If you mean why not using Tang server (Clevis is just a client), I already mentioned it's better to use it. I just wanted to test onidel's vTPM implementation.
Normally I would go with Tang server for remote unlocking.
I'm also not an expert on this stuff so you should do your own research and decide what works best for you
Sydney when? Itching to check it out...
New nodes in Singapore are being deployed and we hope to have it all done this weekend.
Another upstream will be added to our Singapore network next week as well
Spill the name
Does hostuniversal remain primary or the new one?
it was expected to have new Singapore nodes deployed last weekend, but …
the server shipment to Singapore delayed from 1-2 weeks initially to 6 weeks now. vendor shipped servers to the DC with cpu, ram, disk not installed. missing NICs.
deeply disappointing and extremely frustrating experience
I know a green local handyman who might be up for the job
Looking forward to the legendary return at A$15.60 per year — does the Asia-Pacific Bandwidth Pool include the new locations?
I know a teddy bear might be up for the job for Japan nodes...
There's also someone else willing to fly to SG to meet up for food.
There's also a resident benchmeister who missed some choice drinks last time around and so is (or could/should be) more than willing to fly to SG to meet up for those missed apertifs.
Just to be sure @cybertech notices.
wassssuuup
in Guangzhou now.
sure why not 😁
Any update on NYC?
hopefully next week ...
we have migrated Singapore VMs to a new rack. Most VMs were live migrated, resulting in only a few seconds of network disruption during traffic rerouting.
Singapore VMs now support AMD SEV-SNP (kernel support required)
We will be enabling a new upstream (SG.GS) next week.
SG.GS has been enabled! We are now multi-homed in SG. Customers can benefit from improved network, better routing redundancy, and potentially lower latency to regional networks.
And I wish you had floating ip between vms!
it is in progress
Automatic failover will soon be enabled for Singapore VMs at no additional cost