3 ms·

> If you want to be able to migrate a running VM, do you still really need it to start super fast? Yes. "You" is two different people in this sentence. The pe

> If you want to be able to migrate a running VM, do you still really need it to start super fast? Yes. "You" is two different people in this sentence. The person doing the migration is often not the person who owns whatever service is running in the VM. They have uncorrelated needs. As a platform operator, I want to migrate VMs to be able to balance load and evacuate dying hardware. As a service operator on that platform I want high uptime - or, more accurately to this case, low downtime. One of the reasons someone goes for a long-lived service on a VM platform is because the service is in some sense critical: it's Bad News when it drops a connection or doesn't respond. So the operator of that service wants something with a fast restart so that if it ever does need to be bounced, it's back quickly and they return to whatever redundancy level they originally designed to as fast as possible. "Long uptime means a slow boot is fine" has never been true, in my experience.

nik736 4y ago
Just spawn a new VM on a hypervisor and delete the old VM on the hypervisor that is dying. You can also balance load this way.
- regularfry 4y ago
  Assume any suggestion starting with "just" is equally obvious to the operators as it is to you. In this case, it would be helpful to start from the observation that live migration is non-negotiable, which immediately rules out any form of "turn it on then off again."
  - mbreese 4y ago
    In this case, I think the “just” is justified. (Normally I’d agree with you) If you’re starting from the premise that live migration is non-negotiable, then I’d argue that you likely don’t need a quick start. Long lived services can afford a slower start using a different VM technology. We’re not talking hours to provision a server, but the difference between 100ms and a few minutes. My question to you is — what kind of service would need to start fast and be able to migrate? I just don’t see that Venn diagram having a big overlap. But maybe I’m wrong…
    - regularfry 4y ago
      Doesn't matter what the service is. The features are used and therefore valued by two different audiences (who may in some circumstances be the same individuals wearing different hats). Live migration: platform ops. Fast boot: platform users. The platform ops people want to offer the best service possible to the platform users. Fast boot is a feature users may want for their services, so the operators want to offer it. It's directly user-facing, and is a feature users can evaluate on when selecting the platform. The platform ops people also want to offer high uptime and good performance. So behind the scenes they use live migration to mitigate host risk and balance load. Live migration is not user-facing, and is not a feature users can or should evaluate on when selecting the platform, because they shouldn't have to care. > what kind of service would need to start fast and be able to migrate? For ops, all VMs need to be able to migrate. For users, some services need fast boot. Therefore all services that need fast boot also need to migrate.

nik736 4y ago

Just spawn a new VM on a hypervisor and delete the old VM on the hypervisor that is dying. You can also balance load this way.

regularfry 4y ago
Assume any suggestion starting with "just" is equally obvious to the operators as it is to you. In this case, it would be helpful to start from the observation that live migration is non-negotiable, which immediately rules out any form of "turn it on then off again."
- mbreese 4y ago
  In this case, I think the “just” is justified. (Normally I’d agree with you) If you’re starting from the premise that live migration is non-negotiable, then I’d argue that you likely don’t need a quick start. Long lived services can afford a slower start using a different VM technology. We’re not talking hours to provision a server, but the difference between 100ms and a few minutes. My question to you is — what kind of service would need to start fast and be able to migrate? I just don’t see that Venn diagram having a big overlap. But maybe I’m wrong…
  - regularfry 4y ago
    Doesn't matter what the service is. The features are used and therefore valued by two different audiences (who may in some circumstances be the same individuals wearing different hats). Live migration: platform ops. Fast boot: platform users. The platform ops people want to offer the best service possible to the platform users. Fast boot is a feature users may want for their services, so the operators want to offer it. It's directly user-facing, and is a feature users can evaluate on when selecting the platform. The platform ops people also want to offer high uptime and good performance. So behind the scenes they use live migration to mitigate host risk and balance load. Live migration is not user-facing, and is not a feature users can or should evaluate on when selecting the platform, because they shouldn't have to care. > what kind of service would need to start fast and be able to migrate? For ops, all VMs need to be able to migrate. For users, some services need fast boot. Therefore all services that need fast boot also need to migrate.