Hi,
I was hoping to only mention this much closer to the time when it
could actually happen, but a few people have been asking about this
so I thought it was only fair to give an update.
TL;DR version:
We're planning to soon double the amount of RAM offered for the
current price. You'll be contacted individually when this can
happen; hopefully it just happens, but if you're unlucky then you
might need to be migrated or keep the same amount of RAM for a lower
price instead. Do not panic. You can stop reading now. :)
Longer version:
For a while now it has been clear to us that BitFolk has fallen
behind its competitors in how much RAM we offer for a given price
point, and I wanted to reassure you that I have been taking steps to
remedy this. These have included:
- 56GiB of RAM installed across several machines at the recent
maintenance at the end of February.
- Ongoing migration of all customers off of dunkel.bitfolk.com so
that some non-urgent hardware maintenance and a RAM upgrade can be
done.
- New server with 48GiB RAM being prepared for colo now.
We are hoping to double the RAM allocation for the same price, i.e.
the smallest VPS will come with 480MiB RAM and additional RAM may be
purchased 240MiB at a time.
We could of course just offer this right now to new customers, but I
really dislike it when existing customers are not offered the same
deal as new, even if it does make some business sense to chase the
new. So, I'm holding back from doing that until I know it will be
possible to apply the upgrade to the majority of existing customers.
I can't give any firm timescale for this right now; it's going to
happen as soon as possible.
For many customers this is all going to be very simple; you'll
receive an email that says "congrats, shut down and boot again to
enjoy twice as much RAM". That's it. Unfortunately for some of you
it's not going to be possible to "just do it".
Some of you will be on hosts that cannot be economically upgraded.
8GiB DDR2 DIMMs are stupidly expensive; it's cheaper to buy new
machines with 8GiB DDR3. Here's how it's going to work:
Customers with 240 or 360MiB RAM will be upgraded first. That's
because 240 and 360MiB plans won't be available to new customers
afterwards. If we can't upgrade you because the host is out of
RAM then you will be offered migration[1] to a host that does have
enough RAM. If there's no host available with enough RAM then you
will remain with the same amount of RAM and your future renewals
will be cheaper, however we will upgrade you to at least 480MiB RAM
as soon as we can and you will have no choice in this.[2]
Next, customers with 480MiB or more RAM will be upgraded. If we
can't upgrade you then you'll stay with the RAM you have, at the
lower cost.[3]
As soon as we start upgrading people, the new plans will be
available to new customers, although we may run out of capacity
quickly due to upgrading existing customers. Once this happens,
please don't try to cancel your monthly contract and sign up again
to get the extra RAM quicker; I would hope to have upgraded everyone
that I can within a couple of days of starting. :)
As usual if anyone wants to downgrade then they will be free to do
so from their next contract renewal.
However, if:
- you currently have 480MiB or more of RAM *and*;
- you know you don't need twice as much as you have now *and*;
- you're definitely going to ask to be downgraded back towards what
you started with;
then it would be helpful if you could email support(a)bitfolk.com with
your VPS account name and the amount of RAM you'd like to end up
with. We *may* be able to both downgrade you (and give you some
service credit back) and use that RAM to give to someone else. No
promises though; you may have to wait until your next renewal as
normal.
If you have any questions about all this then please just hit reply
to direct them to the users list, or send an email to
support(a)bitfolk.com if you'd rather discuss off-list.
Cheers,
Andy
[1] Migrating your VPS between hosts will require us to shut it down
and then boot it up again, with something like 5-10 minutes of
downtime in between. If a migration is necessary then we'll
contact you individually to co-ordinate the work.
[2] While you may be satisfied that 240 or 360MiB RAM is adequate
for you, I don't want to keep lots of custom plans going and I
don't want to bill below £8.99/mo if possible.
[3] e.g. If you're on 480MiB RAM, 10GiB disk, 100GB/mo data transfer
then that currently costs £13.99/mo. If we couldn't upgrade you
to 960MiB RAM then you will remain on 480MiB but the plan will
only cost you £8.99/mo from your next renewal.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hi all,
now that CentOS 5.6 has finally been released I've just run a "yum
update" to install it.
Despite installing the latest kernel (kernel-xen-2.6.18-238.5.1.el5)
it's not actually booting with it (despite a shutdown and console boot).
I guess I need to do something outside of the VPS (pyGrub?) to get this
working but I don't know what.
Can anybody advise, please?
Thanks,
Mike
Hi everyone
My VPS running Debian Lenny has recently started to crash frequently,
about 6 times in the last week. I've had out of memory conditions in the
past, though reasonably infrequently, so that was my first I thought.
I've bumped my RAM allocation, added extra swap and removed a few
services which weren't strictly necessary but the crashing continues. My
resource graphs don't suggest any memory usage build up before the crash
or anything else untoward going on and the system logs report nothing,
it seems to just go more or less instantaneously.
I managed to capture some of the console output when I got to the machine:
http://pastebin.com/TjZRCebQ
But it had been dead for about 6 hours as I'd been out for the evening,
so it's possible the crucial part was lost before I got to it.
I'm not much of an expert on interpreting kernel panics so I thought I'd
ask if anybody has any greater insight on the cause or how I can capture
the output to disk.
At this point, my only options seem to be to migrate services off to
another system until the system stops crashing, or add more RAM, or
start afresh on a new VPS to see if it goes away.
Regards,
Adam Sweet
--
http://blog.adamsweet.org/
Hi,
At approximately 0442Z today, 2011-04-05, I was alerted that several
VPSes on barbar.bitfolk.com were not responding.
On investigation, the host itself was displaying kernel errors
related to Xen, and was also unresponsive. At this point I decided
to power cycle it.
When it came back up several of its RAID devices would not mount. It
looked like this was just because of the power cycle; a write had
managed to hit one of the disks but not any of the others, and a
mount could be forced. I didn't want to rush into anything though
due to the possibility of data loss.
After some further investigation, I was able to find a way to sync
the arrays and mount cleanly, and boot progressed. As of
approximately 0521Z VPSes have been starting up again on barbar and
this has just completed.
I am not seeing any problems at the moment, though there is high
disk contention due to many VPSes trying to fsck at once and
a background verify of RAID integrity taking place. barbar had
previously been up for nearly 2 years so many VPSes on it require
fsck.
For now we'll be keeping a close eye on the server and later today
will investigate further.
Please accept my apologies for the disruption.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hello,
As you may be aware, BitFolk offers free authoritative DNS services
to VPS customers. This is provided by means of the BitFolk DNS
servers taking a zone transfer (AXFR) from the customer's name
server.
As part of this service we monitor the customer's name server as a
matter of course. That's because it saves everyone's time to know
where any problems lie.
What we currently monitor:
- Customer's server responds on TCP/53
- Query of server for SOA record of the customer's domain produces
a positive, authoritative response
That's pretty good but it misses one class of misconfiguration:
where a customer's name server is misconfigured to refuse zone
transfer from BitFolk's servers.
That's pretty obvious the first time the zone slaving is set up, but
if it happens afterwards then it relies on customers spotting
anomalies in their log files.
If it isn't fixed, then once the "expire" setting of the SOA record is
reached (generally 1-2 weeks for most domains) our name servers
will no longer respond to queries for the customer's domain. This
may come as a shock to the customer. At this point alerts will start
firing for us and we'll probably have to open a ticket.
I would really rather not have to open a ticket either when I spot
the refused AXFRs in my logs, or when I start getting alerts. I
would rather the customer got alerts as soon as AXFRs start failing.
The problem is I can't think of a way to check that AXFR works
without doing an AXFR. :) Can anyone else?
Alternatively, if BitFolk's Nagios tried an AXFR say once a day for
each of your zones would you consider that excessive?
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
"I am the permanent milk monitor of all hobbies!" -- Simon Quinlank
