Hacker News Reader

Comment by amyjess | Hacker News Reader

Well, guess my Linode's getting rebooted again.

As far as I understand, this is the public release of the issue that caused the bigger providers to force the reboots on their customers. This means that there won't be any more reboots (for these issues at least)

Ah OK, that makes sense.

> Well, guess my Linode's getting rebooted again.

Things happen. We should be glad that these sort of security problems are being found and addressed; it would be naive to believe Xen or any other large codebase has zero security problems.

VM's should be regularly patched anyway, which usually requires a reboot now and then. If it were a physical server, the same would be true; just because things are in the "cloud" now doesn't mean they will have infinite uptime.

I understand that sometimes these services reboot and patch with little notice, but this should be built into any Terms Of Service constructed with your client(s); ie. "We will patch and reboot your service for critical vulnerabilities as quickly as possible, which in some circumstances may leave only short notice."

Not to mention, my physical servers take ages to reboot considering all the BIOS and RAID checking they do. My Linodes, being VMs, literally boot in like 10 or 15 seconds. Maybe less. That's really minor downtime. My HP DL380s take several minutes.

You can't migrate to a new kernel on Linode without a reboot anyway, so if you're proud of a 12+ month uptime, you're running a vulernable kernel.

yep. Plus, if you're doing vms correctly, you should be able to spin up new ones quickly to cover ones that go down.

Depends. My physical server isn't shared with anyone. Most local exploits are not a particular worry. A security vuln, almost by definition, requires a shared resource. No sharing, no caring.

That would depend on how "local" a "local exploit" is. If they require physical access to your system, well, then that's one thing. But if "local" is to mean on the network, that's far simpler for an attacker to pull off.

> A security vuln, almost by definition, requires a shared resource. No sharing, no caring

You would only not care if your servers have zero access to the internet and are air-gaped from the rest of your network (even then it's been proven some vulnerabilities can be exploited to gain access).

"local" is generally understood to mean "not the network".

If you're really worried about having to deal with reboots, you can run Terminal on top of Linode and gain the ability to live-migrate all of your workloads (so you never have to take down your application because of the underlying metal rebooting).

I discussed it in detail previously on HN [0], but we give you the ability to live-migrate your workloads, even onto heterogeneous kernels. If that's something you really need, you can get it from Terminal today.

[0] https://news.ycombinator.com/item?id=9120289

Meh, it was just a snarky comment. I don't really care; I'm not doing much with my Linode anyway. I'm mostly just using it as a shellbox/IRC client/Mercurial backup.

If they have one spare xen host they can live migrate all guests from one host to the spare, patch the original host, reboot, then live migrate the spare's guests back to the original, and repeat. Patching them all and rebooting them all at once might be quicker though.

This becomes a physics problem; it's a race between how quickly VMs can be migrated and when the embargo is lifted.

Do you need to migrate them back? Would be faster to just use the newly patched original host as the new spare, and repeat like that.

The XenServer toolstack supports exactly this mode of operation in a pool of physical hosts via a 'host evacuate' operation that live relocates VMs away and brings them back once the host upgrade is complete.

http://docs.vmd.citrix.com/XenServer/5.0.0/1.0/en_gb/install...

Reply on news.ycombinator.com