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
Order Number is: 4103866895 [20th Nov., 2024]
VPS: 1cpu+2GB ram+ 32 GB SSD+ 130MB/s IO
Thanks to this offer.
After that:--
26th Feb., 2025; I have received a promotion from massivegrid with the title "Last Chance: VPS Offer Ends Soon + Major Infrastructure Upgrades!".
28th Feb, 2025, I have been upgraded my this vps with 1 gb more ram and 32 gb more space.
2nd March, 2025; I have generated support ticket to resolution regarding my VPS/server completely down after upgrade.
03rd March, 2025; my VPS has been migrated to a different node.
But I knew today that
My VPS has been converted into HDD from ssd after upgrade.
Everybody can see these result:
root@mg1:~# lsblk -o NAME,ROTA,TYPE,MOUNTPOINT,SIZE,MODEL
NAME ROTA TYPE MOUNTPOINT SIZE MODEL
sda 1 disk 64G QEMU HARDDISK
|-sda1 1 part 1M
|-sda2 1 part [SWAP] 4.5G
|-sda3 1 part / 27.5G
-sda4 1 part /data 32G
sr0 1 rom 1024M QEMU DVD-ROM
root@mg1:~# dd if=/dev/zero of=testfile bs=1M count=1024 oflag=dsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 36.4549 s, 29.5 MB/s
Analysis of Your Frankfurt VPS Disk Performance:
Disk Type (lsblk output)
Model: QEMU HARDDISK (virtualized disk).
ROTA=1: Indicates a rotational disk (HDD), meaning it's not an SSD.
Partitions:
/ (root) → 27.5G
/data → 32G
Having a separate /data partition might help organize storage usage efficiently.
Write Performance (dd test with dsync)
Write Speed: 29.5 MB/s
Time Taken: 36.45s
Interpretation:
The speed is consistent with HDD storage, as HDDs usually have slower write speeds than SSDs.
The oflag=dsync option forces synchronous writes, meaning each write must be committed before proceeding, making it a more realistic test of sustained disk performance.
For this I have already generated a support ticket [Ticket #315955] to PaaS team.
Regards
Dear MassiveGRID Support,
Reference: Order Number is: 4103866895 [20th Nov., 2024]
Thank you for your response. I have conducted multiple tests on my VPS to verify the disk type, and the results indicate that my server is running on HDD storage instead of SSD. Below are the findings:
Command:
bash
Copy
Edit
lsblk -o NAME,ROTA,TYPE,MOUNTPOINT,SIZE,MODEL
Result:
NAME ROTA TYPE MOUNTPOINT SIZE MODEL
sda 1 disk 64G QEMU HARDDISK
|-sda1 1 part 1M
|-sda2 1 part [SWAP] 4.5G
|-sda3 1 part / 27.5G
`-sda4 1 part /data 32G
sr0 1 rom 1024M QEMU DVD-ROM
🔹 ROTA=1 indicates a rotational disk (HDD).
Command:
cat /sys/block/sda/queue/rotational
Result:
1
🔹 A value of 1 confirms that the disk is an HDD, not an SSD.
Command:
sudo smartctl -a /dev/sda
Result (Extracted Key Details):
Vendor: QEMU
Product: QEMU HARDDISK
Rotation Rate: 5400 rpm
Device type: disk
SMART support: Unavailable - device lacks SMART capability.
🔹 "Rotation Rate: 5400 rpm" confirms it is a mechanical HDD, as SSDs do not have a rotational speed.
Previously, I conducted a disk write speed test:
dd if=/dev/zero of=testfile bs=1M count=1024 oflag=dsync
Result:
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 36.4549 s, 29.5 MB/s
🔹 This low write speed (29.5 MB/s) is consistent with an HDD, while SSDs typically have 100 MB/s+ speeds.
Conclusion & Request for Immediate Action
Based on these tests, my VPS is running on HDD storage instead of SSD. Since my original order was for SSD storage, I kindly request the following:
A clear explanation of why my VPS was changed from SSD to HDD after the upgrade.
Immediate migration back to an actual SSD-based VPS as per my original plan.
I appreciate your immediate attention to this matter, as it is impacting my server performance. Please let me know how we can resolve this issue.
Best regards,
DGA
Dear massivegrid!
Could you please fix your virtual network infrastructure? My empty (all services disabled/stopped) debian 12 after 5 minutes of uptime has 3.5GB of incoming traffic on the nic:
If i run iftop, i can see other peoples connections! Also, as a nice bonus side effect, it uses up the monthly bandwidth limit, while i'm not transferring anything...
I have absolutely no clue how in the world could you mess it up this bad. Ticket has been open for some time now, waiting for level2.
None of this is my traffic:
Exactly the same. Since the Friday before last. They said it was a bug. They are fixing it.
750 gigabytes of someone else's traffic in my control panel
At first I thought I was hacked, but no, it's just a "bug".
Let's see what happens after 20T.
Hi @jalalet, it's a custom request regarding IP addresses and as custom request can take some time. It's not a ticket referring to a problem that make the VPSes unusable. The way you wrote the post here might give the wrong impression.
We don't have HDD. Our storages are 100% SSDs. However we have 2000 IOPS limits per VPS to avoid busy neighbor problems.
We'll launch the new offers with higher limits and we'll also launch our VDS with even higher storage limits.
Thank you for your response. However, the evidence strongly indicates that my VPS is currently running on an HDD rather than an SSD:
The drive is identified as a QEMU HARDDISK with a 5400 RPM rotation rate, which is typical of an HDD.
If the underlying storage were truly SSD, the rotation rate should be 0 RPM or not reported at all.
The ROTA value is 1, which means the storage device is rotational (HDD).
If it were an SSD, ROTA would be 0.
Achieving 29.5 MB/s write speed is typical of an HDD but far below SSD performance.
Even low-end SSDs usually exceed 100 MB/s in a synchronous write test.
Please provide concrete evidence to verify SSD-level performance. Otherwise, I have no option to go with this more and will trigger to ask a refund.
Yes, it's the way it's reported at the virtual level. Thank you for your remark, I've passed it to the team to change it.
This result is actually limited by the IOPS, not throughput. If you test it with yabs that tests in various block sizes, thus you get an idea about both IOPS and Throughput.
Make the above tests and let us know. We have 15 days money back guarantee in any case.
Dear @MassiveGRID,
Thanks for the response. Sorry for being a bit pushy with this ticket. My post was not meant to give a wrong impression. It is just that the 15 days money back guarantee is soon gone and the 6 vps's will be useless to me without the custom modification. So it would be good to know soon if these modifications will be done. Ticket #942006.
Feedback from the team:
"It's reported as a rotational indeed because it's not fixed in the old Frankfurt cluster. We're migrating the rest of the VMs to the new Frankfurt cluster this week. It's fixed in the new cluster"
This is from the new cluster:
Hi @jalalet Feel free to ask in the ticket for an extension of the money back guarantee explaining that you won't need the service if the custom IP configuration request can't be done.
Still cannot see snapshot option on panel unless missing something?
I don't believe I have had the extension on my account yet... Can you please extend and price lock?
But they have been changed client managment software from their old to WHMCS. this is the only thing which I have noticed!
"It's reported as a rotational indeed because it's not fixed in the old Frankfurt cluster. We're migrating the rest of the VMs to the new Frankfurt cluster this week. It's fixed in the new cluster"
Thank you for the clarification. If my VPS is still on the older Frankfurt cluster with limited IOPS and rotational storage reporting, I appreciate your efforts to migrate it to the new SSD-based infrastructure.
Please confirm the estimated timeline for the migration and let me know once the process is complete so I can verify performance on my end.
Hey, order number is 7232589612
Please, lock my price.
You also promised to upgrade existing customers to higher iops and new ssds in the first quarter of 2025. First quarter lasts only 2 more weeks
@MassiveGRID Where are you up to in the thread in regards to the extra year and price fix? Not seen any updates in a few days...just making sure you are still around.
Order Number is: 3554894945
Please extend my vps for 4th year and price locking.Thanks
This 4th year promotion already ended on March 4th. Please read the thread.
I want to say that I placed an order on February 28th and sent the order number, but the message has not been returned. Don't I deserve a reward?
Order Number: 9681515478
Please extend my VPS for 4th year and price locking
Cloudflare Warp on my vps
DL-23Mbps/UL-51Mbps
Order number: 1868762257
Thank you in advance
network is horrible now. and please note that, refund policy only apply to 1 product/vps, only purchased at first 15 days in a month. @FAT32
Hi, MassiveGrid,
On March 12th, 2025: your confirmation email on my personal email that my vps has been relocated on your new frankfurt infrastracture.
Today March 14th, 2025, I have tested my vps and **it is still runing on HDD, Here are my findings:
cat /sys/block/sda/queue/rotational → Returns 1 (HDD)
lsblk -o NAME,ROTA,TYPE,MOUNTPOINT,SIZE,MODEL → Still shows rotational disk**
Can you please provide concrete evidence verifying that my VPS is running on SSD storage?
Hello @dgaroorkee,
it is a virtualized device. If the change the value to 0 then speed will NOT increase. They limit your iops and this will NOT change on migration to the new cluster.
Best
snow2k
wordings of massivegrid:
I already know the IO limit is capped by massivegrid.
But please understand my concern i.e. MassiveGrid has not been provided me SSD vps but HDD.
Thanks
OK. They will return a 0. Just wait for the fix. Are you then happy?
Hello,
I have performed performance tests after the SSD migration. While the system recognizes it as an SSD (ROTA=0), the speed results are still much lower than expected for an SSD. I am getting 73 MB/s buffered reads and 5.37ms average latency (should be sub-1ms).
and also I have tested through commond "fio --name=test --size=1G --time_based --runtime=30s --ioengine=libaio --rw=randread --bs=4k --iodepth=32
"
I am experiencing extremely slow disk performance on my VPS, despite the IO being capped at 130 MB/s. I ran an fio test, and the results indicate very low IOPS and poor random read speeds, making the VPS practically unusable.
What This Means:
It’s Not a Software Issue:
And I have been requested for Immediate Action to massiveGrid as:
Please check and confirm: