It’s written specifically to host the Linux kernel, and doesn’t use a bios or a boot loader. If you backported that into another hypervisor, it would probably have to be something like “are we loading a compatible Linux? If so switch to Firecracker mode”. But of course you can do that yourself, with a small shell script that either starts the traditional VM or Firecracker.
> The recommended way to trigger a guest-initiated shut down is by generating a triple-fault, which will cause the VM to initiate a reboot
Doesn’t that mean it can’t distinguish an intentional triple fault to trigger reboot from an accidental triple fault caused by a guest kernel bug which corrupts the IDT? I think it would be better if there was some kind of call the guest could make to the hypervisor to reboot-one is less likely to invoke that service by accident than to triple fault by accident.
I'm used to QEMU VMs being slow and annoying to work with due to them being full VMs, so I was quite surprised to see that this is really just as fast as Firecracker!
That's a generic and well documented stack that utilizes GCP defaults and works out of the box. An "expert" should not take a month to fail to set it up.
I've deployed similar, additionally including GKE, via terraform in a day - Checking TF code for an example 3-env GCP/GKE/CloudSQL stack it's less than 300 LoC
That said, it's not all good - my ongoing complaint with terraforming GCP is that the provider lags behind the features & config available in GCP console - worse than the AWS provider - especially w/r/t GKE and CloudSQL
not sure why this kind of 'sky is falling' post is allowed, particularly when there's no useful information provided
- status boards are rarely up to date, make sure you have your own internal/external monitoring
- a single vm instance does not indicate the health of an entire region. instances can be stopped for a variety of reasons, check the maintenance log and vm console
- when using cloud resources, architecture should not be dependent on a single vm instance
- your cloud architecture and app code should be built to handle transient failures from the start - queueing, retries, backoffs, load-shedding, graceful state failure, etc. use cloud-native services when possible, lift-and-shift of traditional vm architecture to the cloud can be operationally difficult and expensive to run
Serious answer: People will confirm or not in the comments, this post seems pretty reasonable, if a little trigger happy. It could just be a random launch failure.
There's alot that goes into a mail server stack, but it's no more complicated than k8s or other stacks these days. My preferred setup is rspamd/postfix/dovecot/roundcube. The docs are good and the mailing lists are active & archived for easy searching
For a pre-packaged mailserver environment, take a look at mailcow or mailinabox
Don't let "media manager" apps have direct read-write access to files - they tend to spew metadata all over files, and if there's a bug in the software it can corrupt your data. Doubly-so for an internet-facing dependency dumpsterfire like Plex. It's also worth having at-least a DMZ with ingress/egress filtering for any internet-facing services such as Plex - only allow them to connect to what they need.
A filesystem which supports snapshots and rollbacks is good to have underlying your media collection as well (ZFS, BTRFS, etc)
I used FreeBSD on desktop for a number of years and switched over to OSX and I've been through some of the window management pain. I generally do as much as I can with keyboard hotkeys but I do have a trackpad connected to my desktop now as well.
As far as window management, I use contexts for my switcher, rectangle for hotkey-based window management, and stay for automated per-app & per-display window management
This isn't a good example of an RCA - as other commenters have noted, it's outrightly lying about some issues during the incident, and using creative language to dance around other problems many people encountered.
If you want to dive into postmortems, there are some repos linking other examples
The salty sysadmins will note that Microsoft has a track record of botched patches to things like this, with effects ranging from not-remediated to majorly breaking other OS components
https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...
There's also similar microVM project with a bit more container-focused support called Kata
https://katacontainers.io/