Re: google compute engine health check or DoS?

Hi Jose,

On Mon, Mar 24, 2014 at 3:20 AM, Jose R R <Jose.r.r@metztli-it.com> wrote:

Good morning, Jimmy-

On Sat, Mar 22, 2014 at 11:16 AM, Jimmy Kaplowitz <jkaplowitz@google.com> wrote:
> Thanks for the log data. Can I suggest that you mention what happened on the
> gce-discussion list linked from the support page? The right people will
> probably follow up there. (I'm there too.)
>

Well, I just glossed over StackOverflow's:
http://stackoverflow.com/questions/tagged/google-compute-engine

But since I usually favor the deductive/inductive approach to solve
technical problems, I went back to actually probe the issue and act
--subsequently-- on the feedback from the system.

It is only on rare occasions when really something stumps me that I
post to a list and hang around waiting for an answer to my specific
issue.

Sure. If you do end up thinking there's a bug in the hypervisor or other layers of GCE, StackOverflow and especially the gce-discussion list are good places to bring that up without me being an individual bottleneck. Likewise if you find issues with our images or software, but within the Debian context this list is fine for that too. :)

Indeed, I may try the backports kernel, although at the moment (not

being triggered by the suspected event that took it down) the current
kernel seems to perform fine once again.

Glad to hear it's working now.

When I was evaluating HP Cloud's OpenStack (and even Joyent's
SmartOS-based Cloud) I used to build my kernels and thus keep control
of that aspect of the system. However, unless I'm mistaken, I believe
it is still not possible on GCE, right?

That was true for most of 2013 when the product was still in a preview stage, but it changed late last year. (I posted here about a near-final version of that, shortly before the product reached general availability.) Remnants of the old way linger if you use the v1beta16 API, but that's vanishing soon and the v1 API has been current since December.

You can now run whatever kernel you want on GCE, even if it's not Linux. There is no longer a notion of a kernel separate from the image, and we no longer inject a kernel at runtime. The hypervisor jumps to the boot disk's boot record and executes whatever code is there, similar to a physical x86 machine and similar to standard KVM.

This is why we are using Debian's regular GRUB 2 setup and not, say, pv_grub. I've also successfully used non-grub bootloaders.

All of that said, the disk layer supports only the newer and more featureful virtio-scsi, currently not the older virtio-block; and the Ethernet is virtio-net. Debian supports this just fine starting with Wheezy, thankfully. (Possibly squeeze-backports too but not regular squeeze.) More info on building images from scratch, including a list of virtual hardware: https://developers.google.com/compute/docs/building-image

Nor does GCE support hosting a
type 2 hypervisor like VirtualBox, right?

While you can run other virtual environments within GCE, the hardware virtualization support does not pass through to guest-hosted environments. For example, qemu works in GCE, but without the KVM accelerations, so it's slower.

- Jimmy