Converting Windows 7 vmdk to VDI (SOLVED)

[brendonwq]

I need to convert my Windows 7 installation from vmdk to vdi format, because I need to resize the disk. While I know how to do the conversion using VBoxManage to do this, I need to keep Win 7 activated.

Host: Linux Mint 13 (64-bit)
VB: 4.1.12
Clint: Win7 (64-bit)

I've poked around on the web and tried manually editing the vbox files to make sure the UUID and hard drive MAC addresses are the same, but Win 7 keeps getting deactivated.

Thanks!

[brendonwq]

CloneVDI.

[mpack]

Yup. I should note however that disk UUID and MAC actually rank quite low in the Win7 calculation. VM UUID dominates, and should not be confused with media signatures. In your case I assume the VDI went back in the same VM that the VMDK came out of, so the VM sig didn't change.

[brendonwq]

Yes. Thanks for a great application. Much faster than vboxmanage as well!

[Hi-Angel]

Coming here from googling as I found an answer, the proper way to do it is:

Code: Select all

VBoxManage clonehd --format VDI /full/path/to/vm.vmdk output-vm.vdi

For example:

Code: Select all

VBoxManage clonehd --format VDI /mnt/e6383620-7c5f-488f-9b5d-7978ef4f0426/Windows\ 7\ code/Windows\ 7-cl1.vmdk Win7.vdi

CloneVDI won't work for most OSs (though WINE could probably help).

[mpack]

That would be a good suggestion, if the OP hadn't already indicated in the first line of his first post that he was aware of VBoxManage and explained why he didn't want to use it for this function.

Mainly, your suggested method changes the disk UUID, which can affect the outcome in some circumstances.

Yes, CloneVDI is designed to run under Wine, as well as native Windows. This requirement is no more onerous on Linux or OS X than is installing QT. Until Linux acquires a native GUI it will always be necessary to install the appropriate framework, so this is not a new burden. However unlike QT the burden doesn't also have to be born where Win32 is the native API.

[Hi-Angel]

That would be a good suggestion, if the OP hadn't already indicated in the first line of his first post that he was aware of VBoxManage and explained why he didn't want to use it for this function.

Mainly, your suggested method changes the disk UUID, which can affect the outcome in some circumstances.

Ah, thank you, I indeed missed the point of not using VBoxManage. As you're a moderator, I suggest to rename the thread to Converting Windows 7 vmdk to VDI without VBoxManage (SOLVED), because for one comes from search, they usually read everything cursory, mostly to see whether it's their question is addressed, and are there answers. But I indeed should've re-read the topic.

Yes, CloneVDI is designed to run under Wine, as well as native Windows.

Glad to hear! I didn't know.

This requirement is no more onerous on Linux or OS X than is installing QT.

I don't want to look grumbling as this probably isn't super popular app, but I just want to address the point. Wine is nice for one don't have a choice, but Wine does not integrate with Qt or GTK themes, it doesn't have a primary selection, and if one really cares whether the app works with Wine, one have to test it upon any refactoring or adding functionality.

Until Linux acquires a native GUI it will always be necessary to install the appropriate framework, so this is not a new burden. However unlike QT the burden doesn't also have to be born where Win32 is the native API.

Qt is a native GUI. As is GTK. As is EFL. You can write a really native client, to use X11 or Wayland protocols, but believe me, you don't want this.

The point of having crossplatform toolkits is that you can easily write a GUI which would run on both X11 and Wayland, and as a bonus on OS X, Windows, FreeBSD, etc.

Besides, Qt is way more mature than native WinForms, I'm saying it as someone worked with Qt previously, and working for two years with a WinForms app at work. With WinForms there're so much things you have to do yourself. Like handling "Ctrl+Backspace" to delete a word instead of producing a box character in every textbox, and in every widget using internally a textbox. Or allowing scroll of a widget under cursor without cliking on it first.

[mpack]

I feel the need to pull us back to the path. You implied that CloneVDI wasn't a good choice because it required the installation of the Wine framework. I pointed out that all other Linux GUI options also require the installation of a framework. Was I not correct?

A native GUI is one which can be assumed to be present - in all distributions of the OS. QT and etc have to be installed, they are not native to Linux. In fact Linux doesn't have a native GUI. Even X isn't truly native AIUI, though I might accept it as such with caveats. In fact I originally intended to use native Linux widgets when I began developing CloneVDI: except it turned out that no Linux widgets API exists. There is no Linuxy API I could write for which would obviate the need to install the required framework package on every host OS.

By comparison, Win32 has been a supported part of all Windows versions since Windows 95 (it existed before that, but not in all Windows versions). If I target this framework then Linux and OS X users still need to install the Wine framework (if they haven't already), but Windows users don't have to. And that's always going to mean that the majority of my users benefit.

I'm afraid I don't know what "it doesn't have a primary selection" means. Integration with QT or GTK themes: not a requirement of the Win32 API. Also, I don't need to test whether an app works with Wine, I target the vanilla Win32 API, which Wine also targets. I don't undertake that Wine is bug free, any more than I would undertake that some random implementation of QT is bug free. This is the whole point of having an API, i.e. that it allows modular development, without my having to concern myself whether someone else did their bit right.

[Hi-Angel]

A native GUI is one which can be assumed to be present - in all distributions of the OS. QT and etc have to be installed, they are not native to Linux. In fact Linux doesn't have a native GUI. Even Xorg isn't truly native. There is no Linux widgets API which I could target which would obviate the need to install the required framework package on any host OS.

This is because "Linux" as a system usually refers to whole family of OSs, anything with Linux kernel. If you really want to, you can target X11 protocol, because even users with Wayland would still have XWayland too for a long time. But FYI direct usage of X11 is frowned upon, besides being hard (because it is very old protocol).

But what's the motivation for not using a cross-platform toolkit anyway? Is it like you do care for user having to type a command to install libs? Or for taking ≈72Mb of disk space?

By comparison, Win32 has been a supported part of all Windows versions since Windows 95 (it existed before that, but not in all Windows versions).

X11 is from 1987 year ☺

If I target this framework then Linux users still need to install the Wine framework (if they haven't already), but Windows users don't have to. And that's always going to be the majority of my users who benefit.

Well, if that's the point, than you could just statically link the libs.

I'm afraid I don't know what "it doesn't have a primary selection" means. Integration with QT or GTK themes: not a requirement of the Win32 API. Also, I don't need to test whether an app works with Wine, I target the vanilla Win32 API, which Wine also targets. I don't undertake that Wine is bug free, any more than I would undertake that some random implementation of QT is bug free. This is the whole point of having an API, i.e. that it allows modular development, without my having to concern myself whether someone else did their bit right.

"Primary selection" aka "primary clipboard", is the thing that allow you to select a text with mouse, then paste it anywhere with middle mouse button.

Another thing I just remember: WinForms scrollbar doesn't support pressing with middle mouse button, forcing immediate scroll to the point. Very annoying.

I can't just tell you all the downsides of WinForms with comparison to Qt because I recall them occasionally, I don't have a list or something ☺ But I remember there were much.

[mpack]

I'm not sure why you bring up WinForms: it isn't a part of Win32, nor is it used by CloneVDI.

You also seem to be missing the point in a number of other areas: my point about Win32 being supported since Win95 is not about longevity (though that stability is important too), the important bit is SUPPORTED BY THE OS. Every version of Windows since Win95 on is capable of running CloneVDI "out of the box" i.e. without modification of either CloneVDI or the basic OS install.

I DO USE A CROSS PLATFORM API, IT IS CALLED WIN32. I apologise for shouting, but you appear to be deaf to the point if I say it normally. I wouldn't choose QT because I need a cross platform API - I already have that. The question that needs to be answered is, what else does QT etc give me?

There's no need to explain that Linux is a family of distros with no controlling entity. That's kinda my point too. One can't target Linux because really, there's no such thing. It's a lot of incompatible things.

Static linking a 72MB QT library would still require one to download 72MB of additional data which the majority of my users get zero benefit from. Perhaps you have not noticed that the CloneVDI download is 123K. Statically linking a 72MB library would grow the download by 600% (maybe compression would help some). Not all of us live on a campus with super fast broadband, so having to downloading 72MB to perform a function that is already performed quite well by the host OS is extremely annoying.

[Hi-Angel]

I'm not sure why you bring up WinForms: it isn't a part of Win32, nor is it used by CloneVDI.

Hmm, my bad, I thought it's what the default toolkit is called. Anyway, then I'm talking about Win32 GUI API. For a proof you can start any native binary, e.g. network settings window, and you will see all the nuances I mentioned because unlike app I'm doing at work, someone didn't care to workaround the problems for native apps.

You also seem to be missing the point in a number of other areas: my point about Win32 being supported since Win95 is not about longevity (though that stability is important too), the important bit is SUPPORTED BY THE OS. Every version of Windows since Win95 on is capable of running CloneVDI "out of the box" i.e. without modification of either CloneVDI or the basic OS install.

Do you know why Wayland started? Because X11 is all the way backward compatible. You can just start an app from 1987 year, and it will work (if some other API didn't break).

I DO USE A CROSS PLATFORM API, IT IS CALLED WIN32. I apologise for shouting, but you appear to be deaf to the point if I say it normally. I wouldn't choose QT because I need a cross platform API - I already have that. The question that needs to be answered is, what else does QT etc give me?

There's no need to explain that Linux is a family of distros with no controlling entity. That's kinda my point too. One can't target Linux because really, there's no such thing. It's a lot of incompatible things.

Static linking a 72MB QT library would still require one to download 72MB of additional data which the majority of my users get zero benefit from. Perhaps you have not noticed that the CloneVDI download is 123K. Statically linking a 72MB library would grow the download by 600% (maybe compression would help some). Not all of us live on a campus with super fast broadband, so having to downloading 72MB to perform a function that is already performed quite well by the host OS is extremely annoying.

My point is that Win32 is not cross-platform. Yeah, it's probably works with Wine, but for a random user from Internet it's not obvious if it's working at all, because Wine have a bunch of function stubs.

If you want to call the app cross-platform because of Win32, you have to have a winelibs release.

P.S.: anyway, I suggest to stop the discussion because even if — let's imagine — I'd convince you, you definitely won't start rewriting the app again.