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
@BlueVM it's a good thing. I had completely forgotten I had an annual VPS with you. I just looked over the notification email thinking it was sent out to all people in your database then I saw a tracking link come through and was pleasantly surprised.
Transfer was awesome better as Buyvm ;P
Not quite on the same scale.
One involves vzmigrate between rented dedis, the other is moving ~100 nodes 500 miles :P
EDIT - But good job to Justin n' co' on the migrations so far!
Francisco
@Francisco
Yes, one involves risking everything vs risking nothing.
yeah ok i take it back ;P
Alright guys. There is no need to compare how other hosts migrated. That causes problems.
As in "the migration" causes problems?
Probably that it will create more drama here then needed.
You cant compare apples and hacksaws and expect the same result.
Btw, i'm still waiting in line
no 15 now
@MiguelQ @MikHo - Drama between providers is not necessary and it's a huge waist of time. Our services and BuyVM's services are similar and we both do things differently.
@Francisco - Actually we purchased new hardware to replace our old hardware. We will be either A renting out our old hardware or B using it for KVM clients. We do own both.
BTW, when are you planning to add KVM stock? I'm interested in your Atlanta location
@BlueVM
My point exactly, I might have not written it clear enough.
@Jack - We got an IP block from ColoCrossing it was apparently used by a previous provider (or from what we can tell a few providers). We're waiting on them to update the SWIP information to BlueVM Communications LLC.
We did scrub it to make sure the blocks were clean, however we're just not listed on them yet. We own 192.210.208/21.
@Jack - I'm not expecting much, it's a holiday.
In Buffalo, then?
Yes.
Yup.
HVH doesn't own the entire /21, someone at CC fat-fingered the SWIP.
I'll check for you.
Send in a ticket, we have KVM space in Atlanta.
No worries, I was no 47 this morning. It will take the time it needs.
I dont use it right now anyways.
I've be hit by a number of these host-migrations over the past year. I'm amazed at how often my "virtual" servers end up in the back of a real trucks
But not BlueVM
We don't see the need for physical moves since we have many networks, not just one.
@sleddog - Why simply physically move your hardware when you can upgrade your entire openvz client base to better hardware at the same time?
Remote host said: 550 SC-001 (SNT0-MC3-F28) Unfortunately, messages from 192.210.211.* weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
New IP Block on colocrossing have some issues with microsoft mail servers.
@imperio - Do you have:
Microsoft is particularly picky and that's what that error code shows, that Microsoft didn't like your records.
The issue is it was working on the previous IP.I have changed spf record to new IP and requested a rDNS for the new IP.Unfortunately support answer was:
This reminds me that you do not have control on the new IPs yet, means you have started migration beside not having control on the new IPs.
@imperio - What Jack said is correct. We fully intend to have RDNS setup for our clients shortly.
@Jack @BlueVM If I can not send mail to microsoft servers and if you do not have rDNS control yet that means for me you do not have control of the IPs yet.I do not want to debate the percentage of control as the reality is sending mail to microsoft servers and mail servers that checks rDNS is impossible right now.
@Jack - HyperVM has a server side RDNS module, but it's crap so we use tickets for the entries.
@imperio - Ok. I understand.
@BlueVM
I appreciate your migration process script.The thing annoyed me is accusing customer as rDNS is incorrect while you do not have the control to change it.