On Sun, 15 Feb 2009 17:13:37 +0000
Iain Lane <iain(a)orangesquash.org.uk> wrote:
> Now the problem I'm having is with configuring the new kernel (this
> was the only dpkg issue with the upgrade, not bad). Here's the output:
>
> laney@cripps:~$ sudo dpkg --configure -a
> Setting up linux-image-2.6.26-1-xen-686 (2.6.26-13) ...
> update-initramfs: Generating /boot/initrd.img-2.6.26-1-xen-686
> Searching for GRUB installation directory ... found: /boot/grub
> warning: grub-probe can't find drive for /dev/sda1.
> grub-probe: error: Cannot find a GRUB drive for /dev/sda1. Check your
> device.map.
I got the same sort of error trying to update the kernel in Lenny.
I currently am running linux-image-2.6.18-6-xen-686 and tried to update
to linux-image-2.6.26-1-xen-686. In my case grub-probe could not
find /dev/xvda1
--
John Lewis
"Kingsclere Families" website uses the GeneWeb genealogy data server
--
John Lewis
Debian & the GeneWeb genealogical data server
Hi folks,
BitFolk has changed bank, so for those of you who pay by standing
order, please could you amend this to:
Bank: Barclays
Sort: 20-41-41
Account: 83665453
Name: BITFOLK LIMITED
These details are also present on all invoices generated as of now,
and are also listed at:
http://bitfolk.com/contact.html
I will also be contacting you individually any time I see a bank
transfer to the old (Abbey) account. After a month or two I will be
closing that account.
I am happy to see that Barclays supports Faster Payments:
http://www.business.barclays.co.uk/BRC1/jsp/brccontrol?task=popup1group&val…
Also it would help a great deal if while you are amending your
standing orders you could make sure that you have your VPS name as
the reference.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi folks,
If you're going to FOSDEM (http://fosdem.org/2009/) then I hope to
see you there, feel free to say hello. :)
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi,
I'm interested in running Xen on a spare computer in order to get some
hands on experience with virtualisation and other aspects of running
linux and networking. My Bitfolk VPS is running Debian, and I have the
most experience with that distribution, however I think I saw that
Bitfolk were using Ubuntu on new servers and was wondering which
distribution would be best for me? As the computer will be used purely
for experimenting with I thought I'd run the unstable or testing
branch of whichever distribution in order to get the latest code.
I'd like to keep the installations as minimal and well documented as
possible so was wondering whether debootstrap (or the appropriate
alternative) would be the best way to go for installation of the OS?
Its likely that I might want to use the host for staging/testing of my
virtual machine destined for my Bitfolk VPS, is there anything I'd
need to do in particular to make sure that it'd be compatible? or
would any Xen domain be easy to copy over?
Finally, as I said above I'd like to document and record the
configuration and running of the host as much as possible. I
previously tried using dokuwiki for a similar purpose, however I had a
few issues when it came to printing the documentation and would like
to make keeping and (if possible) automating documentation as easy as
possible. So I'd appreciate any suggestions on that.
Thanks in advance for your help, sorry my email is a bit long! :-)
For ages I've been getting annoyed at Xen for having to set the
Independant_WallClock setting back to 1 after every reboot, so that
NTP will work.
I even added this stuff into the config;
http://os-drive.com/files/docbook/xen-faq.html#virtual_guest_clock
And despite thatm it still got reset to 0 after a reboot. Today I
found the answer.
Today I found this in my config file:
# Set independant wall clock time
xen.independant_wallclock = 1
10 points for anyone who spots as I did the immense FAIL...
Hi all,
I wish to set up sending email from my vps - and I have been testing
php's mail facility.
Mail to two of my addresses (@googlemail.com, and @ntlworld.com) work
just fine. Three out of three got through - all within 2 or 3 seconds.
Mail to my preferred address - this one - is not being delivered,
although the call to mail returns true. (three out of three lost).
I wish to know why.
The server handling my incoming mail, is running on my firewall, with a
"dynamic" IP address, and thus the IP is in various black lists. Could
this be the reason for the non-delivery? Seems a long-shot to me. Why
should bitfolk care?
Any other reason I could check out?
Regards - and thanks for you input.
Ian
Hi,
I've been fielding a number of questions on this subject so I
thought it was best to give an update.
After the hardware upgrades earlier in the month it became apparent
that not all machines were seeing all the RAM. In fact, it was
looking pretty bleak:
Host Previous RAM New RAM Recognised
config. config. RAM
--------------------------------------------------
corona 4x2G 4x2G 8G
curacao 4x2G 2x4G, 4x2G 16G
kahlua 2x4G, 4x2G 4x4G, 4x2G 16G
kwak 4x2G, 4x1G 4x4G, 4x2G 16G
obstler 6x2G 2x4G, 6x2G 16G
That's 20G missing out of 40G purchased.
At the time it was fairly obviously a software issue and in any case
we did end up with more RAM than I started with, so I left the RAM
installed and carried on with the work.
Further research reveals that 32bit Xen is limited to 16G RAM even
in PAE[1] mode. This was a surprise to me - my understanding of PAE
was that it would allow up to 64G RAM to be used, and indeed that is
how it works in Linux. But Xen is not Linux (the Xen hypervisor
boots Linux, but it's not Linux). There is no possibility of making
32bit Xen see more than 16G RAM unless someone in the community
writes that functionality.
Why does Bitfolk even use 32bit software when all the servers are
64bit-capable? Well, it is actually only since islay was removed at
the last datacentre visit that all hosts became 64bit-capable, but
the main reason was that for a long time 32bit seemed the most
stable and offered the most stable choice of guest operating
systems. While all the supported Xen guests do have 64bit releases,
not all of these were of the same quality as their 32bit
counterparts. And running 32bit guests on a 64bit Xen host has only
been possible relatively recently. Finally, there is no real
performance gain going 64bit on a server as small as the typical
VPS. It will actually be worse, as processes use more memory under
64bit.
These decisions were due for a rethink soon though, and for the next
set of servers I had already decided to go 64bit Debian Lenny or
Ubuntu Hardy, while keeping 32bit guests.
So, in order to use the full RAM that has been installed, a 64bit
hypervisor is necessary. As I say, all the servers are
64bit-capable, and I've been advised that the hypervisor and Xen
kernel from Debian Lenny are stable when running 32bit guests on
64bit hypervisor.
My plan at the moment, therefore, is to go to that configuration on
the new server that I installed at the last visit: faustino. Over
the next couple of days I will be moving some of my own and Bitfolk
infrastructure VPSes onto this server as a means of testing its
stability.
Provided that goes well, then next week I would like to step up the
testing by putting customer VPSes onto it. I'm looking for a few
volunteers for that. It will involve a shutdown, 10-15 minutes of
downtime then being booted on the new server. As reward for
volunteering I'm offering a week of free service and the promised
120M RAM upgrade when booted on faustino. Please drop an email to
support(a)bitfolk.com if you'd like to volunteer for this.
I want to be very careful about doing this fairly radical
configuration change on existing stable servers each of which is
holding 30-50 customers, but until I do it I can't give the RAM
upgrade. Most of the existing servers are full in terms of IO
capacity so I do not need to do this for any reason other than to
give you the extra RAM. Therefore, my judgement call is on the side
of caution and I am not going to change configuration for at least a
month, in order to do sufficient testing on the new server.
If you want the RAM upgrade before this then you are going to have
to be moved to the new server.
Provided I get enough volunteers and of course depending on things
being stable, then probably towards the end of next week I will
alter the web site to reflect the RAM upgrade and new customers will
also go onto the new server.
Finally, when the time comes that I'm satisfied that the
configuration on faustino is stable, I will install the same
software on all existing servers. On each server in turn I will:
- Install the new hypervisor and kernel
- Update VPS configurations to have the additional RAM
- Shut down every VPS on that server
- Reboot the server into the new hypervisor/kernel and confirm it
sees the full amount of RAM
- Start up every VPS on that server
I will most likely do that one server per night at 1AM GMT or
something.
So, that's the plan for all this. I'm sorry that it hasn't been as
simple as originally planned, but the PAE thing was rather
unexpected.
I hope that by including volunteers in the testing process and
offering the RAM upgrade with it that it will be a suitable
compromise for both adventurous people who need the extra RAM, and
cautious people who prefer to stay with the stability known prior to
this month. Not that I would even be contemplating this if I
thought it wasn't going to be stable, but there is always risk!
If you have any further questions, feel free to ask on- or off-list.
Cheers,
Andy
[1] http://en.wikipedia.org/wiki/Physical_Address_Extension
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
My VPS seems have been also targeted as an unwitting participant in
this attack ...
http://www.merit.edu/mail.archives/nanog/msg14471.html
cod:~# tshark "port domain and (host ns.isprime.com or host ns2.isprime.com)"
Capturing on eth0
0.000000 66.230.160.1 -> 212.13.194.x DNS Standard query NS <Root>
1.142336 66.230.160.1 -> 212.13.194.x DNS Standard query NS <Root>
1.611227 66.230.128.15 -> 212.13.194.x DNS Standard query NS <Root>
2.521652 66.230.160.1 -> 212.13.194.x DNS Standard query NS <Root>
3.615401 66.230.128.15 -> 212.13.194.x DNS Standard query NS <Root>
5.481957 66.230.160.1 -> 212.13.194.x DNS Standard query NS <Root>
5.622538 66.230.128.15 -> 212.13.194.x DNS Standard query NS <Root>
... I think you get the idea.
Until I firewalled [1] these hosts from my DNS server, I was bouncing
back failures to the (legitimate) hosts; apparently the incoming
packets are being spoofed to over 750,000 DNS servers causing the
"real" hosts to get DOS'd by the failure responses (5Gbit of traffic
:S).
Not sure if any one else is experiencing the same issue, (I only
noticed as I run an iftop for other reasons).
~Mat
--
[1]
# iptables -I 1 INPUT -p udp --dport domain -s ns2.isprime.com -j DROP
# iptables -I 1 INPUT -p udp --dport domain -s ns.isprime.com -j DROP
Hi,
I'm afraid that obstler seems to have entered some sort of kernel
deadlock; new network connections and logins can't be initiated, nor
VPSes started, so I am going to have to reboot it shortly.
Apologies for the inconvenience.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
Hi,
One day in January between Saturday 10th and Sunday 18th inclusive I
intend to be taking down all BitFolk servers in turn to perform a
memory upgrade and some other work. It shouldn't take more than
about 30 minutes per server.
This will be followed by an increase of RAM allocated to each plan,
i.e. a free RAM upgrade. I do not know exactly how much yet. [1]
I will clarify the exact date as soon as possible.
Other work that will be taking place:
- Upgrade of hypervisor, since the version in use on kahlua seems to
have fixed a couple of annoying bugs that the others still have [2]
- Switch to high efficiency PSUs where possible
- Accurate power draw measurements for each server
- islay.bitfolk.com will be replaced by newer hardware
Cheers,
Andy
[1] For all paying customers, unless for some reason we have agreed
otherwise. Will likely be in the region of 120 - 240M.
[2] Notably:
- the one where if you reboot sometimes, then the VM comes back
with no networking; and
- the very intermittent one where after transferring ~3.7GiB of
data, a VM will lose all networking and have to be rebooted.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
Encrypted mail welcome - keyid 0x604DE5DB
