I saw that you use KVM, but which linux system do you run on your hypervisors?

Thanks

We use Ubuntu on the hypervisors and the kernel is run through the hypervisor.

We are in the process of building and testing where we allow customers to run their own hypervisors.

Unlike OpenVZ we are very up to date on the kernels because it increases stability and performance. With OpenVZ its more paravirtualization and totally different from KVM or Xen and how it's often sold is through over provisioning which increases the likelihood of problem as well.

Okay thanks. I saw that my vps runs 3.2.0-24 virtual. It runs on ubuntu 12.04 and when i did a dist-upgrade, i quicly saw 3.2.0-31 virtual. I saw myself "the vps lets me to install a custom kernel? interesting" So I loaded it, it installed without trouble, I updated grub to boot on 31, but 24 loads always anyway, even if 31 is set as default, but if you say that the kernel is run through your hypervisor, thats ok, and thats why the kernel will always be the one which is run on the server. Thanks

We'll be making updates for this in the future but it is currently a small subset of power users that are upgrading systems and running their own kernels.

As that number grows we'll prioritize that higher up the queue, right now we are working on a few other elements that will benefit all users of DigitalOcean.

But you can always up-vote the features that you are most interested in by logging into the Control Panel and clicking on the "Feedback" icon.

Thanks

Build iPXE with DOWNLOAD_PROTO_HTTPS defined. You can then use dnsmasq or the like on a private interface to allow the user to boot anything.

Having a "virtual machine" implies exactly that--a machine. Your service is stellar overall. Please don't continue to cripple it by not providing this critical feature.

I did exactly what the OP did... and I'm still seeing 3.2.0.24 even if I dist-upgrade(d) to last 3.2.0.40 and edited /boot/grub/menu.lst accordingly. No change after six months?

So, if I understand it correctly, these droplets are sold like KVM but behave like OpenVPS: I have no control over the kernel. This is quite a limitation !! I created the droplet with the default kernel but I thought, "no problem, even if it's quite old, I can upgrade it whenever I deem it feasible". But now I'm stuck to... to what? I mean, if you've not updated images for NEW droplets in six months, I must change how I intended to use digitalocean, from "let's see if I can bend this at will and use it in production" to "ok, if I continue using it, remember it must be only for testing".

I agree: I just discovered this, and as a new customer, I'm pretty disappointed.

This is a big deal. For example, there is a local root exploit that became public recently, and affects a HUGE number of kernels - including CentOS 6.4 (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2094). Yet, I can't upgrade my kernel without talking to you?

So if someone finds any flaw in anything running on my droplet, and/or manages to get user-level access - they can immediately get root until the kernel is upgraded. That's really not good.

You can update the kernel on your droplet from the Settings tab so you're always up to date on security patches.