Sorry to keep bugging you guys about cloning, but another thought occurred to me, and ISTM we'll never get a better chance to get this right.

Suggestion: if they are not already present, then add DMI entries to the <ExtraData> section of the cloned VM .vbox file, to ensure that the cloned OS sees all the same BIOS signature strings that it saw before cloning. Otherwise this forum is going to be filled with complaints from guys who cloned a Win7 VM.

Oh - and can I also say that I love the "Dolly the Sheep" graphic. Inspired!

If they do exist then fine you copy them, otherwise if they are missing then I'm suggesting that you create them: if nothing else then please create the one which reflects the VM-UUID into the guest.

Basically, if these strings don't exist then when the guest OS asks for the DMI strings it will get back defaults, and these will not be the same defaults the original VM used. A particular problem is that a change in VM UUID triggers reactivation in a Win7 guest. To overcome this you have to insert a DMI string whose value equals the old VM's UUID. That way the guest see no change in the "hardware".

A believe a related problem can occur with cloned drive UUIDs which are used by some Linux guests to identify the drive to be mounted. I'm not sure if fixing that one is quite as easy however.

I think a simple option, like with the MAC addresses, to copy the original VM UUID as hardware UUID is enough. Any other DMI code is already copied, so don't bother with making that optional. With this, you can avoid the possible reactivation in Windows Guests. Describe the setting in the manual why it might be wanted to be used.

Sasquatch wrote:I think a simple option, like with the MAC addresses, to copy the original VM UUID as hardware UUID is enough

Why does it need to be optional? What's the downside of doing what I suggested for every cloned VM, without asking? Note that my suggestion follows the principle that the clone should match the original wherever possible.

IMHO, I don't like adding options to a user interface unless there is a very good reason, and it simply can't be avoided. I would not have conceded the optional MAC address: it sets a bad precedent, exactly as I feared it would.

mpack wrote:Suggestion: if they are not already present, then add DMI entries to the <ExtraData> section of the cloned VM .vbox file, to ensure that the cloned OS sees all the same BIOS signature strings that it saw before cloning. Otherwise this forum is going to be filled with complaints from guys who cloned a Win7 VM.

Does that translate to "complaints from guys who violate Microsoft licensing conditions"?

Perhaps what's really needed is an option to create an exact copy vs. using the original as a template. In the former case, all MAC addresses, UUIDs, serial numbers, etc. would be kept, in the latter they'd be re-generated to keep the identifiers unique. The choice really must be made by the user because only the user knows how the clone will be used. Sometimes the user wants an exact copy which is in some way a backup of the original, in other cases the user wants to start with a known state but continue using them as separate entities.

michaln wrote:Does that translate to "complaints from guys who violate Microsoft licensing conditions"?

They will be in the mix, I'm sure. But how is branching clones ethically different from branching snapshots?

In any case I'm no expert on what latest MS licenses allow and don't allow, and nor do I think features should be avoided because they might be abused by some individuals. And incidentally, I do not use Win7 guests myself (and in any case I know how to provide the DMI stuff manually) - my POV is that of a volunteer on this site who wants to make the software as user friendly as possible, and who is also not looking forward to answering the anticipated Win7 question ad infinitum.

michaln wrote:Perhaps what's really needed is an option to create an exact copy vs. using the original as a template. In the former case, all MAC addresses, UUIDs, serial numbers, etc. would be kept, in the latter they'd be re-generated to keep the identifiers unique. The choice really must be made by the user because only the user knows how the clone will be used. Sometimes the user wants an exact copy which is in some way a backup of the original, in other cases the user wants to start with a known state but continue using them as separate entities.

While not as eloquently posted I made basically the same suggestion the 16th of June in the dev mail list and was told that adding the ability to retain the UUID structure in the GUI was paramount to being yet another weird entry that was really not needed.

I still use Dons' CloneVDI tool for this reason alone. I test a lot and use this feature to save/restore the guest if or should I say when I toast the install or simple what to save the current working state. Note, I do not use snap shots. Personally I have not had the best experience with them. As for using this for nefarious reasons I spent plenty for replacement software because I had eaten up all of my authentications re-installing the same windows in virtualbox until I started cloning and I only run (1) copy period. But I see your point about the illegal use of the same. It's a quandary!