51–60 of 121 posts
Earlier quoted context omitted.
I see a ton of value when you have instances on a private network with no shell access and want to debug them without setting up a bastion instance.
Yep, this might very well enable whole deployments where there is no SSH access anywhere.
Earlier quoted context omitted.
I get this sense they are very conservative in their feature set there? Nested VMs for example are supposed in GCP, Azure and Oracle clouds I think, but not AWS. VM migration too I think exists in GCP at least, but not AWS. It's interesting.
Who needs nested virtualization when you have bare metal? VM Migration is only for maintenance on GCP -- and customers can't control it, just Google. AWS can hot patch live systems in place without any downtime, so, that's better than a migration (which has a brown out / maintenance period)
Even when you offer bare metal, it’s actually still nice to have nested virt! Otherwise, every node has to be a full sized host. So when you have a K8s cluster or similar with a pile of nodes and want to allow some teams to use it (e.g., Android emulator, firecracker, whatever), it’s really nice not to have to say “okay, this group requires full bare metal hosts that they manage themselves”.
tl;dr: nested virt is still a nice to have so that all your infrastructure looks the same.
Edit: Also, you can trigger migration yourself if you want (gcloud compute instances simulate-maintenance-event), but that's mostly to convince yourself that nothing bad will happen.
Oh thank god. I had a customer once that erased their SSH keys, and had a running database cluster on EC2 that they couldn't get access too anymore. That was... fun. This is a long time coming.
Sure there’s down time involved, but you can always stop and mount the volumes elsewhere and then update the SSH keys.
Not gonna lie... if I ever got into a situation where I needed serial access to an EC2 instance, I'd just retire the EC2 instance and spin up another one.
That’s a good default posture. What sucks is when you’re trying to debug a system that has OOM-killed sshd and then is behaving generally poorly. If you replace your instance with another one, you just get another OOM kill.
At this point, without interactive serial port access, you get to replace whatever you’ve got on the box with more logging statements. That’s a totally reasonable approach, but with interactive serial ports you can poke at it and root cause a lot faster.
Edit: Also, Linux seems to always kill sshd first. (Part of this is survivorship bias, of course).
Not gonna lie... if I ever got into a situation where I needed serial access to an EC2 instance, I'd just retire the EC2 instance and spin up another one.
I have waited 10 years for this :D. https://forums.aws.amazon.com/thread.jspa?messageID=979374
This is super useful if you are in the game of building images, or highly tweeking init systems and/or the kernel. For general consumers, not much value IMHO.
I see a ton of value when you have instances on a private network with no shell access and want to debug them without setting up a bastion instance.
https://docs.aws.amazon.com/systems-manager/latest/userguide...
I have waited 10 years for this :D. https://forums.aws.amazon.com/thread.jspa?messageID=979374
Wow. Out of curiosity just checked if the other cloud providers have it - both Azure and GCP have this feature already. Azure got it ~ Feb 2020, GCP Feb 20201.
IIRC, we launched interactive serial port access sometime in late 2014. For example, mbrukman answered a SO question on Jan 2, 2015 with connect-to-serial-port [1]. I don’t recall when we gained fancier IAM controls for it, but we’ve had it forever (and I think getting / view only was there at public launch).
[1] https://stackoverflow.com/questions/27734763/how-do-you-acce...