←back to thread

128 points darthShadow | 6 comments | | HN request time: 0s | source | bottom
Show context
TZubiri[dead post] ◴[] No.42812385[source]
[flagged]
1. hobofan ◴[] No.42812412[source]
> It's a naturally vendor neutral tech so migrating should be trivial.

So are the OCI standards that grew out of Docker and now are mostly used separate from (official) Docker.

Is there even a vendor neutral VM image format?

replies(3): >>42812445 #>>42812452 #>>42812605 #
2. regularfry ◴[] No.42812445[source]
Yeah, raw disk images. If you give me a block device, I can boot off it.

Slightly less trivially, anything qemu-img handles should probably be considered at least in the neutral direction, if not actually neutral.

replies(1): >>42812487 #
3. TZubiri ◴[] No.42812452[source]
>Is there even a vendor neutral VM image format?

The vendor neutral standard is the Operating System. You don't need the format of the OS at disk to be standardized, that assumes a wild misconception of OS.

The OS integrates with hardware so you typically can't just copy an image between different machines and expect it to work, what's standard is the installation procedure which can be part OS provided and part hardware manufacturer/host provided.

Yes the process for installing the operating and configuring system is a bit of glue that might not be vendor neutral, but if you are obsessing over that and spending time with stuff like terraform you are missing the forest for the trees. It's like open source zealots complaining that github is closed source. You are 99% of the way there, forget about the 1% last mile and just port it manually.

4. TZubiri ◴[] No.42812487[source]
The standard would be BIOS/UEFI, and Partition schemas like GPT/MBR in that case.

However it's not always the case that you can just raw copy with dd some OS and expect it to function. OS integrate with hardware and installation can produce a unique binary OS specialized for that hardware. If you can magically dd an OS or swap an OS disk from machine to machine, then it's because of OS and kernel dev magic and can cause problems down the line.

In reality the best solution in my experience is to deploy an installation process, which usually is provided by the Host provider directly, and then run my own installation steps on userspace.

The fact that this process might be slower or involve human steps is more often a feature than a bug, and it's not something that can be solved by containers (someone has to fire up the host VMs when there's too many containers too). You can always use providers that automate new vm and even hardware deployments like AWS if you really need intra-day deployments.

replies(1): >>42815290 #
5. oftenwrong ◴[] No.42812605[source]
OCI image _is_ a vendor neutral VM image format; the runtime spec includes facilities for running VMs: https://github.com/opencontainers/runtime-spec/blob/main/con...
6. regularfry ◴[] No.42815290{3}[source]
> it's not always the case that you can just raw copy with dd some OS and expect it to function.

No, and that's not the context here.

> The standard would be BIOS/UEFI, and Partition schemas like GPT/MBR in that case.

I think the trick of wedging an MBR into the first sector of an ext2 partition with extlinux as a bootloader should still work. You really don't need much.