Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Nice surprise from c-servers

2»

Comments

  • zedzed Member

    The rep was already pretty clear that any concerns were irrelevant and it's your own fault for being a customer, I don't know how much more you should expect!

  • alfatarsosalfatarsos Member, Host Rep
    edited January 27

    @silkatron said:
    Not feeling super confident after the Veloxmedia mess so will give it a couple of days and hope for the best.

    It will be the best option, really...

    We're midway into the migration of the last two servers, Frankfurt and New Jersey. Frankfurt is 67% done, New Jersey actually ended up last and hasn't started yet due to an IPv6 provisioning issue, so we're not deploying anyone there just yet, but it will be fixed.

    We've specified a maximum 72-hour window for the migration but last time we were able to get everyone on board in 24/36h. This time we will need a little more than that, probably on the 48/60-hour mark.

    Doing my utmost to get this question complete as soon as humanly possible. I do apologize for the natural inconvenience this causes - but it is for the best, for everyone at these servers.

    @AlteredParadox said:
    Well, 2/3 moved. One's been offline for 24 hours at this point... still have yet to actually receive an email about the process. I've gotten the service deleted/create emails, but none of the ones informing of schedule/timing. Kinda weird.

    We've also sent an e-mail exactly equal to the last KB article, which was January 23rd (and which postponed the start of this last block by ~24h).

    Since the service with Mailjet was not good, I've done it this time through the standard SMTP provider, exactly the same e-mail and provider from where you recieve those service e-mails, but in an entirely different way.

    What you're saying is that you didn't recieve this as well?

    Can you send me your e-mail through the DMs so I can check and have examples to submit, please? I'll need to have an explanation on this one from the e-mail provider... I'm truly not happy with this. It's not normal.

  • @alfatarsos said:
    Can you send me your e-mail through the DMs so I can check and have examples to submit, please? I'll need to have an explanation on this one from the e-mail provider... I'm truly not happy with this. It's not normal.

    Sure thing, sent it along. Email issues aside, I like the new panel and the new vms seem an upgrade from their previous ones, so all in all not bad!

    Thanked by 1alfatarsos
  • Emails just received regarding service activation - not tried anything out yet, but just wanted to send receipt confirmation and thanks @alfatarsos

    Thanked by 1alfatarsos
  • Same here, my 3rd service looks to have finished migrating and is active in virtfusion, and as usual I did receive the activation emails.

    Thanked by 1alfatarsos
  • alfatarsosalfatarsos Member, Host Rep
    edited January 27

    Sorry for the slight laziness, but after going around the clock in order to get everyone on board even before the timeframe, I'm a little tired, as you may understand... so I'll paste the exact message we've sent on the OGF... and get to sleep. Yes, at 11AM local. (Any pending tickets will be seen later today along with the secondary disks).

    Thank you for your time. :)

    "In the meantime, and after 12 continuous hours of work, we're pleased to say the migration to VirtFusion is complete!

    Users that were at Zeta.5 New Jersey and that had any of the JumboDisk VPS services: we still have your data intact and, later today, we'll attempt to reinstate the secondary disk image with all the HDD data to your VPS, on a per-user basis, again, one by one. The plan and the VPS are already active, but it's recommended, for today, not to use the secondary disk until we get to everyone (we're talking about some TBs of data, but not many users to move).

    Thank you very much everyone for your patience throughout this process!

    Just as before, any VPSes/services that could be missing, please send us an e-mail to migrations[at]c-servers.co.uk, until February 7th."

    Thanked by 2silkatron truemagic
  • oomeroomer Member

    I also did not receive the Jan 8 email or any subsequent emails until the Virtfusion activation one this morning. I have about 20+ emails between Nov and Dec 10 back and forth with support on tickets I had going. I'm cool with it since I use the Jumbodisk as a fourth backup but I was panicking for 15 minutes until I read the Knowledge Base and LET.

  • @Xrmaddness said:
    This is the email I received January 8th:

    SolusVM - VirtFusion User Migration 2026

    Dear Xrmaddness,

    Hope this e-mail finds you well, first and foremost.

    As we had already announced upon our VirtFusion deployments, we have deprecated our SolusVM 2 platform, and are starting to deploy VirtFusion accross all our servers.

    What does this mean for you?

    Due to significant underlying differences between SolusVM and VirtFusion, and after thorough technical evaluation, we have decided not to migrate, but to entirely redeploy all the existing VPS servers - but on an orderly fashion, allocated timeframes and at a relaxed pace, so everyone can plan, backup and adjust accordingly. This is the cleanest, most safe way of executing this migration, and we apologize in advance for all the inconvenience it may carry, but there are significant networking and cloud-init differences that were tested and seen to contribute to a migrated VPS potentially stay without any Internet after the migration, depending on the implemented OS.

    This way, we ensure everyone gets an operational system after reimplementation, and everyone can benefit of the new networking advantages VirtFusion provides over SolusVM.

    A good procedure will be to take notes of your existing configuration, or do a formal backup of your system, prior to the migration. An example of these tools is rsync. But you can use any others, at will, depending on your needs. C-Servers will take no responsibility on data loss for this migration, it's a significant system change and we can't unfortunately ensure what, otherwise, we'd be very much glad to ensure.

    For JumboDisk Storage VPS users in Zeta.5 New Jersey

    Your first disk will always be redeployed, just like other users, but we found we're able to retain the original filesystem pools and file structure - and with that, autonomously retain the files. This will allow you, due to the way we've originally decided to implement your JumboDisk secondary disk, to retain all files without any loss whatsoever, despite the fact that any symlinks or any configurations dependent on the main VPS node (e.g. special filesystems installed to your secondary disk from your main VPS node) will fail, if you've done any.

    Despite this specific, we still strongly recommend, nevertheless, that you execute backups on your existing files, as we may have the exceptional need of reimplementing your disk without any files whatsoever for any unforeseen reason. It's strongly recommended to do so, may we insist. It's also a question of responsibility.

    You'll have no difficulties on doing backups of your data - we have plenty of available traffic at Zeta.5 New Jersey and a 10 Gbps line is available, ensuring multiple concurrent backups will be able to be executed simultaneously. Therefore, backup at will, with the peace of mind that we will still try to implement our best scenario possible at any moment.

    Does this change incur any additional cost?

    Despite the significant improvements this change brings, the change will be done at no extra cost whatsoever for anyone. By doing so, it will probably be a good time to stress that C-Servers is explicitly accepting to reduce their margin, in exchange for customer retention - VirtFusion costs more than 2x what SolusVM costs.

    We will compensate the additional cost offset of 12 USD per server through several internal changes we'll implement upon migration, which will be destined to allow a reasonable offset of the new pricing, but which will be mostly transparent to the existing customers, all while allowing some new customers in. Some of them were already implemented at the support level, others will follow technically.

    What is the calendar for these changes?

    The expected calendar is as follows:
    » Zeta.6 Finland - 11/01/2025, 10h00 GMT
    » Zeta.7 Finland - 11/01/2025, 22h00 GMT
    » Zeta.5 New Jersey - 24/01/2025, 10h00 GMT
    » Delta.1 Frankfurt - 25/01/2025, 10h00 GMT

    All migration procedures are expected to occur for a period of up to 72 hours per server, with downtime expected starting at these days and times for everyone. Migrations will be executed starting from the highest-paying customers down to the lowest-paying customers on a per-plan basis, and you will recieve three e-mails: one for cancellation, the other one for reactivation, and the third one directly from VirtFusion and confirming that your server is now a VirtFusion VPS.

    All procedures will be manual. There will be no Specialized Support for these customers during this time outside of the Live Chat or the e-mail: [email protected]

    But I have an essential function going on at the VPS! How can I ensure I'll get the least downtime possible?

    If you have an essential task, e.g. a professional task going on at the VPS, and you would like to ensure that your VPS is redeployed first so you can get things up and running again as soon as possible, we do provide a priority service. Simply e-mail us at the previously described e-mail ([email protected]) stating your VPS name, your account name and e-mail associated, and that, due to a professional task, you need to have things up again on a given VPS as soon as possible.

    Upon reprovisioning your VPS, you'll have priority over the regular per-plan order and be deployed first, benefiting from the lowest downtime possible. This is the best that we can possibly do, in full respect for your needs. We also again apologize for the inconvenience of this migration, but we ensure you'll get better served than you are now.

    Changes for Delta1 users on VPS plans under 512MB RAM

    There's one single change that may be noticed, and it's on Delta1 customers (Xeon E5-2695 v4) with VPS plans equal to or below 512MB of RAM: due to the mixture of increasing bandwidth costs and increasing hypervisor costs in Frankfurt, we will have to introduce a slightly lower CPU priority to the existing plans (implemented in VirtFusion through cgroups) which may increase IOwait on a given VPS system.

    However, it's also probably a good time to mention this: these customers have went from a IPv6-only reality, to a NAT64 + IPv6 reality, and now to a full IPv4 NAT + full IPv6 reality, at a price point that basically doesn't exist on the market at this point: paying for IPv4 NAT + IPv6 like if it was an IPv6-only VPS. While we are ensuring that the cost is honoured, being already a sensitive topic for some of our customers; that we don't do increases; and that a usable service is still always provided and tested; it is essential to guarantee that things are sustainable and, on that particular node, it will have to be done this way.

    For those customers at Delta1 that would like to have a normal priority level, they have two options: upgrading to existing Frankfurt VPS plans with at least 1GB of RAM on the node, or requesting to the Migrations e-mail stated below a price update to the current reference pricing of NanoVPS-384. Either of the two will remove the priority difference.

    Any other questions?

    You can always use the e-mail: [email protected].

    Best regards,
    Tiago Severino
    C-Servers Systems Administrator

    Weird, I did not get this email at all, and it's missing from Received Email on the portal as well. I did receive emails below so I guess it's not a receiving problem from my end:

    • Service Activation Detail
    • Your service has been activated
    • etc

    While I'm happy to have my service restored, I hope I won't miss the next email—especially if data loss is anticipated :)

  • @truemagic said:

    @Xrmaddness said:
    This is the email I received January 8th:

    SolusVM - VirtFusion User Migration 2026

    Dear Xrmaddness,

    Hope this e-mail finds you well, first and foremost.

    As we had already announced upon our VirtFusion deployments, we have deprecated our SolusVM 2 platform, and are starting to deploy VirtFusion accross all our servers.

    What does this mean for you?

    Due to significant underlying differences between SolusVM and VirtFusion, and after thorough technical evaluation, we have decided not to migrate, but to entirely redeploy all the existing VPS servers - but on an orderly fashion, allocated timeframes and at a relaxed pace, so everyone can plan, backup and adjust accordingly. This is the cleanest, most safe way of executing this migration, and we apologize in advance for all the inconvenience it may carry, but there are significant networking and cloud-init differences that were tested and seen to contribute to a migrated VPS potentially stay without any Internet after the migration, depending on the implemented OS.

    This way, we ensure everyone gets an operational system after reimplementation, and everyone can benefit of the new networking advantages VirtFusion provides over SolusVM.

    A good procedure will be to take notes of your existing configuration, or do a formal backup of your system, prior to the migration. An example of these tools is rsync. But you can use any others, at will, depending on your needs. C-Servers will take no responsibility on data loss for this migration, it's a significant system change and we can't unfortunately ensure what, otherwise, we'd be very much glad to ensure.

    For JumboDisk Storage VPS users in Zeta.5 New Jersey

    Your first disk will always be redeployed, just like other users, but we found we're able to retain the original filesystem pools and file structure - and with that, autonomously retain the files. This will allow you, due to the way we've originally decided to implement your JumboDisk secondary disk, to retain all files without any loss whatsoever, despite the fact that any symlinks or any configurations dependent on the main VPS node (e.g. special filesystems installed to your secondary disk from your main VPS node) will fail, if you've done any.

    Despite this specific, we still strongly recommend, nevertheless, that you execute backups on your existing files, as we may have the exceptional need of reimplementing your disk without any files whatsoever for any unforeseen reason. It's strongly recommended to do so, may we insist. It's also a question of responsibility.

    You'll have no difficulties on doing backups of your data - we have plenty of available traffic at Zeta.5 New Jersey and a 10 Gbps line is available, ensuring multiple concurrent backups will be able to be executed simultaneously. Therefore, backup at will, with the peace of mind that we will still try to implement our best scenario possible at any moment.

    Does this change incur any additional cost?

    Despite the significant improvements this change brings, the change will be done at no extra cost whatsoever for anyone. By doing so, it will probably be a good time to stress that C-Servers is explicitly accepting to reduce their margin, in exchange for customer retention - VirtFusion costs more than 2x what SolusVM costs.

    We will compensate the additional cost offset of 12 USD per server through several internal changes we'll implement upon migration, which will be destined to allow a reasonable offset of the new pricing, but which will be mostly transparent to the existing customers, all while allowing some new customers in. Some of them were already implemented at the support level, others will follow technically.

    What is the calendar for these changes?

    The expected calendar is as follows:
    » Zeta.6 Finland - 11/01/2025, 10h00 GMT
    » Zeta.7 Finland - 11/01/2025, 22h00 GMT
    » Zeta.5 New Jersey - 24/01/2025, 10h00 GMT
    » Delta.1 Frankfurt - 25/01/2025, 10h00 GMT

    All migration procedures are expected to occur for a period of up to 72 hours per server, with downtime expected starting at these days and times for everyone. Migrations will be executed starting from the highest-paying customers down to the lowest-paying customers on a per-plan basis, and you will recieve three e-mails: one for cancellation, the other one for reactivation, and the third one directly from VirtFusion and confirming that your server is now a VirtFusion VPS.

    All procedures will be manual. There will be no Specialized Support for these customers during this time outside of the Live Chat or the e-mail: [email protected]

    But I have an essential function going on at the VPS! How can I ensure I'll get the least downtime possible?

    If you have an essential task, e.g. a professional task going on at the VPS, and you would like to ensure that your VPS is redeployed first so you can get things up and running again as soon as possible, we do provide a priority service. Simply e-mail us at the previously described e-mail ([email protected]) stating your VPS name, your account name and e-mail associated, and that, due to a professional task, you need to have things up again on a given VPS as soon as possible.

    Upon reprovisioning your VPS, you'll have priority over the regular per-plan order and be deployed first, benefiting from the lowest downtime possible. This is the best that we can possibly do, in full respect for your needs. We also again apologize for the inconvenience of this migration, but we ensure you'll get better served than you are now.

    Changes for Delta1 users on VPS plans under 512MB RAM

    There's one single change that may be noticed, and it's on Delta1 customers (Xeon E5-2695 v4) with VPS plans equal to or below 512MB of RAM: due to the mixture of increasing bandwidth costs and increasing hypervisor costs in Frankfurt, we will have to introduce a slightly lower CPU priority to the existing plans (implemented in VirtFusion through cgroups) which may increase IOwait on a given VPS system.

    However, it's also probably a good time to mention this: these customers have went from a IPv6-only reality, to a NAT64 + IPv6 reality, and now to a full IPv4 NAT + full IPv6 reality, at a price point that basically doesn't exist on the market at this point: paying for IPv4 NAT + IPv6 like if it was an IPv6-only VPS. While we are ensuring that the cost is honoured, being already a sensitive topic for some of our customers; that we don't do increases; and that a usable service is still always provided and tested; it is essential to guarantee that things are sustainable and, on that particular node, it will have to be done this way.

    For those customers at Delta1 that would like to have a normal priority level, they have two options: upgrading to existing Frankfurt VPS plans with at least 1GB of RAM on the node, or requesting to the Migrations e-mail stated below a price update to the current reference pricing of NanoVPS-384. Either of the two will remove the priority difference.

    Any other questions?

    You can always use the e-mail: [email protected].

    Best regards,
    Tiago Severino
    C-Servers Systems Administrator

    Weird, I did not get this email at all, and it's missing from Received Email on the portal as well. I did receive emails below so I guess it's not a receiving problem from my end:

    • Service Activation Detail
    • Your service has been activated
    • etc

    While I'm happy to have my service restored, I hope I won't miss the next email—especially if data loss is anticipated :)

    Oh good point, i never even thought about that - I also don't have the emails in the received email in the portal, though I do have all the service activation emails and whatnot.

    Thanked by 1truemagic
  • stxshstxsh Member
    edited January 27

    I didn't mind the communication because I've been actively following this provider for months and aware of their plans. Execution was a bit rough (as far as communication/transparency/email deliverability), but overall -- I'm satisfied with my upgrades.

    I was previously on a 7950x, noticed my CPU changed:

    SC: 2726
    MC: 4809
    

    Ryzen -> Genoa. :) Very nice.

    Outside of that, network and service itself has been reliable and performant. I've picked up a bunch of their packages from various locations over the last few months and I've come across a few hidden gems.

    I noticed the new Dallas location. Good luck with your expansion/sales and thanks for the upgrades @alfatarsos!

    PS: VirtFusion Alpine Linux script seems to have a network bug (IPv4 works fine, but IPv6 does not). I haven't looked in to why yet; network interfaces appears fine, so I'll let you know when I do.

    Thanked by 1alfatarsos
  • oomeroomer Member

    I started with c-servers during Black Friday, and deployed ipv6 for the first time in my life. This redeployment was easier because of the internal ipv4 that Virtfusion provisions, allows me to bootstrap my Debian net install and then ssh in and add ipv6 afterwards.

    In November, I set up Debian up entirely with ipv6 but because the gateway is outside the /64 you have to alt-f2 and manually intervene. Today, I have to intervene to temporarily disable ipv6 because the Debian installer would not continue.

    I am just leaving this snippet of info for any Debian loving users out there, redeploying using Self-Install on c-server's new Virtfusion platform.

    echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
    ip -6 addr flush dev enp3s0
    ip -6 route flush dev enp3s0
    ping google.com
    
  • @alfatarsos said:
    Everyone will be reactivated, it's part of the SolusVM - VirtFusion migration. We've sent an e-mail beforehand with this, it's (unfortunately) expected behaviour. Our apologies for any inconvenience caused.

    Not quite. All the data was deleted too!

Sign In or Register to comment.