Yeah, I know. The OP's use case seems legitimate, however; at least I can see why he would want to do it that way.

Looks like the OP is using snapshots of a static "gold image" to generate the new VMs' virtual hard drive.
One way to get the desired result is to make 2 snapshots (one with init3, one with init4) and use a snapshot of those as the new VM virtual hard drive...
This way, the script used to generate the VM would decide which init will be used, not a script inside the VM.

Then you have to remember to change two images instead of merely one. (Your way is how I'd probably do it, to tell the truth, but I can see why someone else would want to maintain only one image.)

Of course the additional advantage of your way is that adding a new special MAC address doesn't require re-creating the VM image to include that address for the internal test. I guess that the path of least resistance depends upon which changes the fastest: the list of special MAC addresses or the contents of the VM image (outside of the special MAC address list).

You don't have to change any images.

This is what he uses:
read_only_gold_image --> snapshot

This is what I would use:
read_only_gold_image --┬-> read_only_snapshot_init3 --> snapshot
.................................└-> read_only_snapshot_init4 --> snapshot

That's two images to manage.

They are read_only static snapshots, that take a few Kb of space... there is not much to "manage".

You already do this with your "read-only Qemu image", yes?

They are not modified.

No, they are not.
Like I said, they are read-only
That is why I don't understand what you mean by "That's two images to manage".
Manage what?

Since the dynamic changing from init3 to init4 seems complicated, I thought of an alternative solution.
Please disregard if it does not help in your use case.

According to your setup, both images have a different setup. One is rc.3, other is rc.4.

Yes, but only have to change the snapshots once, on creation, then use them the same way you use your current image (read-only) on every new VM you make.

When you make a new VM you are using snapshots, right?

Tested it, it works.
I mark the thread as solved although I'm open for any other solution.

Aha.

qemu appears to accept an "-append" option (from "man qemu" and scrolling down a hell of a lot)...

...so you can have exactly one VM image that has its default initlevel at 3. Move your "which ones do I want to use runlevel 4" logic out of the VM and into whatever is launching the VMs. Just add "-append 4" to the qemu command line for those special VMs and they should goto runlevel 4 when they start.

(Any runlevel that you provide on the kernel command line overrides /etc/inittab)

2 members found this post helpful.

The -append is only allowed with the -kernel option, which I don't use.