CloneVDI tool - Discussion & Support

[BasMevissen]

Hi mpack,

Thanks for maintaining CloneVDI. Can you please make the source code of version 2.50 available too? I would like to use it to recompile it on Linux (using the Wine libraries). That works fine, at least for 32 bit. For 64 bit, there are quite some changes needed to the source code. But that is not Linux or Wine specific, it is because the Win32 and Win64 API's differ.

Cheers,

Bas.

[mpack]

I haven't decided yet whether I want to keep giving away the source code for everything new I develop in the future. Open source as a moral concept is not something that I've ever really bought into. Frankly, I'm not sure how I benefit from the deal. As recent events in this topic has shown, all that it enables is for someone to take control of my work and take it in an unsympathetic direction. I almost never use anyone else's source code, so "greater good" arguments don't much appeal to me either.

Besides, is it really the case that Wine doesn't let you run Win32 executables on a 64bit host? Windows can do it, so I don't see why Wine would be so limited.

[BasMevissen]

Well, you made the 2.10 version source code available already. So I hoped you would be willing to release the latest version as well.

Regarding the 32/64 bit in my previous post (now a bit edited): Wine runs 32 bit applications fine on 64 bit Linux. What I said was that the code cannot easily be compiled to a 64 bit version because the 64 bit Windows API is different that the 32 bit one. It doesn't matter whether you compile it on Linux or with Visual Studio on Windows.

Cheers,

Bas

[mpack]

I can see no need for CloneVDI to ever be a 64bit app - it simply doesn't need that much RAM.

I assume you understand that an application running on a 64bit capable CPU can use 64bit arithmetic regardless of whether the host OS is 32bit or 64bit. So the OS doesn't hinder the app from using the ALU to its full potential. The only reason for favouring a 64bit OS is if you specifically want the OS to be 64bit, e.g. because you want to allocate >2GB RAM in a contiguous chunk, because that's the max that Win32 OSs typically allow. However CloneVDI's largest RAM allocation is only a few 10s of MB, so my RAM requirements would have to grow by a factor of x 200 or so, and that ain't gonna happen.

[BasMevissen]

The reason to have CloneVDI a 64-bit app is because nowadays Linux systems can be used without any 32-bit application support. Especially servers are usually installed like that.
What I want to achieve is to have CloneVDI be a native Linux application. Unfortunately, that requires quite some porting effort as winelib is insufficient.

[stefan.becker]

I think there is a problem with VDIs with big size and growing character.

I think you could try it yourself.

Create a VDI growing, Size 610GB. Install a Windows, restart => working.

Start CloneVDI, choose the VDI, select "keep old UUID" and "Compact drive while copying".

The result does not work in VBOX.

Error message on startup (details):

Code: Select all   Expand viewCollapse view

Could not open the medium '/daten/VirtualMachines/VirtualBox/VDI/Windows8Test.vdi'.
VDI: invalid header in '/daten/VirtualMachines/VirtualBox/VDI/Windows8Test.vdi' (VERR_VD_VDI_INVALID_HEADER).
VD: error VERR_VD_VDI_INVALID_HEADER opening image file '/daten/VirtualMachines/VirtualBox/VDI/Windows8Test.vdi' (VERR_VD_VDI_INVALID_HEADER).


Fehlercode:
NS_ERROR_FAILURE (0x80004005)
Komponente:
MediumWrap
Interface:
IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}


VDIs with a smaller size (<= 200 GB) works without a problem.

And converting wirh an older version (CloneVDI 2.05) works, too.

[mpack]

Thanks Stefan, I'll investigate this weekend. I doubt I'll have time before then.

[stefan.becker]

No problem, i have ever backups from all guests, so nothing lost.

BTW, thanks for the great tool. Works perfectly with WINE. Under Windows 10 i checked this, too. I thought first maybe its a WINE Problem. But same result, same error message at startup.

[mpack]

No problem, i have ever backups from all guests, so nothing lost.

Well, as you know I have a policy against modifying the original files, only ever the clone, so thankfully it is impossible to lose your original (no matter what bugs might be in CloneVDI) - unless you delete it yourself without having checked the clone! Which would be a complement I guess, but not something I'd ever recommend...

[stefan.becker]

Normally i delete them, in this case too. All others are smaller and converted without a problem. Only this one. I checked it a day later.

But as i said: I have always Backups, so no problem.

[mpack]

NEW VERSION RELEASED - v2.51 (see root message for download link).

Please note that I've released a new version of my CloneVDI tool (v2.51). The only purpose of this release is to fix a bug which causes problems whenever CloneVDI creates a VDI whose logical size is greater than 256GB. In short it got the alignment of the image wrong, overlapping part of the block map. This bug was introduced in v2.50 when I changed the code to align major file components on 1MB boundaries, as has become the recent VirtualBox convention. Happily VirtualBox detects the bad header, so this was not a covert failure.

Thanks to Stefan Becker for pointing out the error and making the report clear enough that I could easily reproduce it. I rarely create very large VDIs, so it might have been a long time before I found this otherwise.

Enjoy!

[stefan.becker]

Hello mpack,

downloaded, checked, OK!

Works now perfectly with bigger images.

Thanks!

[mpack]

Excellent, thanks.

[LenW]

...What I want to achieve is to have CloneVDI be a native Linux application. ...

I don't see why you would want to do that, except perhaps as an exercise
for your own purposes. (Sorry to bring this up, in case you have changed
your mind in the last few months.)

The problem with depending on Wine to run an application, as I understand
it, is that in general, if the app works, it's almost by accident. It is too
easy for the app developer to do something non-standard to get some kind
of perceived benefit, without caring if it breaks Wine. I just can't
picture Don doing this. I can't speak for him, but I bet that if
something did happen to CloneVDI to make it fail under Wine, that he would
regard that as a bug and fix it. (Comments, Don?)

It seems from this discussion that building a native Linux port would
amount to forking the project, with all of the risks, duplicated effort,
and brittleness that entails.

If my supposition is true about CloneVDI's future under Wine, what are
the advantages to a native port? To put it bluntly, why would I choose a
native Linux port over using Wine to run Don's latest version?

[mpack]

Yes, you have it right. I regard Win32/Wine as the most complete and best supported multi-platform graphics API available, available on all important hosts (and comes built in on the most important). I don't see it as merely a way to run Windows apps on Linux. I explicitly target the Wine subset of the Win32 API and would consider it a bug if there was an incompatibility.