virtualbox.org

I have tried to run a VM backup (via snapshotting) on a different host.
I am running v5.1.26r117224 under Ubuntu Linux 16.04.3 (headless) using x86_64 architecture.
The kernel is stock: v4.4.0-93-generic.

This is what I have done:

1. I have create two subsequent snapshots for the same machine (on the main host).
2. I have copied the whole folder to the secondary machine.
3. I have stopped the VM on the main host.
4. I have deleted the second snapshot (on the secondary host).
5. I have restored the first snapshot (on the secondary host).
6. I have restarted the VM (on the secondary host).

I have got this error message:

Error: failed to start machine. Error message: Failed to load unit 'cpum' (VERR_INVALID_FLAGS)

I suspect that there can be a problem with the CPUs of the two hosts (main and secondary).
In particular I have:

MAIN
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 63
model name  : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
stepping    : 2

and

SECONDARY
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz
stepping        : 7

Despite there's no documentation, I have then tried to use the a "vboxmanage modify" command to set "--cpuid-portability-level".
I have got another error message:

~ vboxmanage modifyvm na1 --cpuid-portability-level 1
VBoxManage: error: The machine is not mutable (state is Saved)
VBoxManage: error: Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component SessionMachine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "COMSETTER(CPUIDPortabilityLevel)(ValueUnion.u32)" at line 657 of file VBoxManageModifyVM.cpp

Any hint on how to solve the problem (provided that's possible)?

TALIA.

[SOLVED]
Please check this message.

Saved states cannot be transported to different CPUs.
If your snapshot contains a saved state you need to discard the saved state after restoring the snapshot before you can start the VM.

Martin wrote:Saved states cannot be transported to different CPUs.
If your snapshot contains a saved state you need to discard the saved state after restoring the snapshot before you can start the VM.

I havent's saved any state, just done a snapshot.
Actually two: the second has been taken "just" to get the first one "static". And in fact it's been deleted before restoring the first one.
Unless "saved state" == "snapshot". Isn't it?

What'd be the meaning of the "--cpuid-portability-level" switch?
Can this actually help in my case?

"VBoxManage: error: The machine is not mutable (state is Saved)"
is a clear message. The guest is not powered off / shut down, it is in a saved state.
The saved state includes the CPU state of the "old" CPU which cannot be used on the new CPU.
Did you take the snapshot while the guest was running?

I haven't ever tried to take a snapshot of a non-running VM, though.
Is there a way to stop and ask the original VM to run in a "compatibility" mode so I can copy it on a "slightly different" CPU?
Where is the documentation for the "--cpuid-portability-level" switch?

By the way, I have checked the documentation.
It's a little bit confusing: is "saved state" the same as "snapshot"?

Notorand.IT wrote:is "saved state" the same as "snapshot"?

Not in the least. A snapshot is essentially a record of disk contents (all connected disks) and VM settings at the time you told it to make a snapshot. However if you snapshot a running VM then by necessity it saves the state of running memory as well. And the latter is a "saved state". Saved states are also created when you suspend a VM.

I haven't suspended the VM, though.
Anyway, what about that undocumented "--cpuid-portability-level" switch?

What about it? You have the user manual, that means you know as much as I do.

In any case I have a vague memory that that flag had to do with teleporting, not saved states. If you want portability, don't save state. If the saved state is unusable, discard it.

mpack wrote:What about it? You have the user manual, that means you know as much as I do.

There's nothing about it in the User Manual. This is why I am sking here.

mpack wrote:In any case I have a vague memory that that flag had to do with teleporting, not saved states. If you want portability, don't save state. If the saved state is unusable, discard it.

It seems NOT to be about teleporting. The teleporting chapter isn't mentioning it. And even so, "teleporting" is not what I need to do (backup).

Is there a way to define a VM CPU to be a specific model or to have specific features so that a "Xeon E5-2620 v3" and a " Xeon E5-2407 0" can run the same snapshot?

In principle yes, but not after the fact (when you already have a saved state). The --cpu-portability-level switch might work, but it's not all that well tested. Forcing a specific CPU profile might also work. You are basically doing something VirtualBox was never designed for, so you're on your own.

The fundamental problem is that you can't change the CPU behind a running OS/application's back without blowing things up.

If only I had more details about those "<0...3>" switch values I could stop the original VM, change its "CPU portability level" and restart it.
After that, the snapshots would be with the proper "CPU portability level" thus allowing (in principle) the migration.

Maybe I am wrong, but at least this part of the VirtualBox project seems to be quite immature and with too little documentation.

Just shut down the original VM completely before you transfer it and you will not have any problem.

Martin wrote:Just shut down the original VM completely before you transfer it and you will not have any problem.

I need to be able to make backups without stopping the VM.
And to run any of them on a possibly different host.
Thus the whole discussion.
Any working idea is welcome.

If the target host has a different CPU that wil not work.
You can only get "crash consistent" backups with the current state of the disk similar with when you would just had removed the power cord on a physical system.
You are currently transfering the actual memory / CPU register state (= "saved state") which is not usable for a restore.
In this case you have to discard the saved state before powering on the VM and it will start like after a power crash.