←back to thread

128 points darthShadow | 2 comments | | HN request time: 0.46s | source
Show context
TZubiri[dead post] ◴[] No.42812385[source]
[flagged]
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 #
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 #
1. 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 #
2. regularfry ◴[] No.42815290[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.