Exported 'multiattach' .ova imports as 'normal'

[rgoers]

Running VB on Redhat Enterprise Linux machine. Created Win7_64 VM...

Just as the title says -

I created a Win7 Enterprise VM under VB and got it set up the way I want it. I am exporting the vmdk which is tagged as 'multiattach' - I need to install this VM on other RHEL machines. I used the VB UI to do the export, since it's something I need to do infrequently. I'm not opposed to using VBoxMange to do this step, if it will resolve the problem I'm seeing.

I have a script that I run when ssh'd into another Linux machine, that imports the exported .ova file into the VB UI. My script uses VBoxManage to do the import, and it appeared to be working perfectly... at least I thought everything was working great, until I found the imported file is no longer tagged as "multiattach", but has reverted to "normal".

I have looked at the VBoxManage 'export' and 'import' commands and cannot see any place where I can specify to preserve the 'multiattach' flag (status, or whatever it's doing). Does anybody know how I can get my .ova file imported in a way that maintains the 'multiattach' status? I've spent a couple days chasing my tail on this one... any help would be greatly appreciated.

[mpack]

Copy the VM folder with contents, don't export. On target machines, use Machine|Add... to register the local copy.

Exported "appliances" uses a VMWare standard. If you use a feature which VMWare didn't anticipate, then it won't be part of the VMWare standard.

[rgoers]

Hmmm... appreciate the reply. That's the way I was doing things. Unfotunately, that workflow process leaves lots to be desired.

I was very excited about the export function because it reduced the size of the VM from 60GB to 7.5 GB. Copying the 60GB file to several computers really sucks down the bandwidth. Also; using "Machine > Add" means I have to touch the machine, WITH THE USER LOGGED ON. That's what I was trying to avoid.

Being able to do things in the background, without having to walk to the physical machine, and *especially* without having to have the user present and logged on has many advantages.

[mpack]

I was very excited about the export function because it reduced the size of the VM from 60GB to 7.5 GB.

You can achieve the same thing yourself, simply by zipping up the VM folder. AFAIK the compressed variant of VMDK does exactly that, using libzip or whatever the open source zip lib is called.

Also; using "Machine > Add" means I have to touch the machine, WITH THE USER LOGGED ON. That's what I was trying to avoid.

Whether you import or Machine|Add, a new VM is registered for the current user... I don't see a substantial difference. In any case you only need to use Machine|Add the first time. After the VM is registered it can be kept in sync by copying the VDI file, provided you don't use snapshots.

[rgoers]

Whether you import or Machine|Add, a new VM is registered for the current user... I don't see a substantial difference. In any case you only need to use Machine|Add the first time. After the VM is registered it can be kept in sync by copying the VDI file, provided you don't use snapshots.

I appreciate the suggestions... I'm pretty new to this and can use all the help I can get.

I probably should have mentioned this up-front. I'm attempting to do this remotely. I'm supporting many users (150+) spread out over several locations and buildings (dozens, some well beyond walking distance). I'd prefer to find a way to *not* have to physically touch every machine.

I'm not worried about keeping machines "in sync". That's why I'm trying to get the VM imported in multiattach mode (my original 'problem'). In multiattach mode, the changes get stored as differencing files, which means the end user can never bugger up the original VM.

[mpack]

The user can't mess up the original VM regardless - he can only mess up his local copy. But you can mess things up royally, by relying on fragile differencing schemes. In any case an exported appliance is always stand alone, AFAIK no differencing scheme works with that (not snapshots, not linked cloned, and not shared (multiattach) disks).

[rgoers]

The user can't mess up the original VM regardless - he can only mess up his local copy. But you can mess things up royally, by relying on fragile differencing schemes. In any case an exported appliance is always stand alone, AFAIK no differencing scheme works with that (not snapshots, not linked cloned, and not shared (multiattach) disks).

I don't even want the user to be able to mess up his/her local copy of the vmdk. That's why I have been trying to resolve the issue of getting the disk to import as 'multiattach'. That way; if they screw something up, they can create a new VM, attach it to the existing and unaltered multiattach vmdk, and go. All I do is import the .ova file once from the server, and then they have the vmdk on their local machine. If they mess something up, let *them* fix it by creating an new VM based on the existing multiattach vmdk. They can't mess up the local vmdk, because it is 'immutable' for all practical purposes. That takes me out of the loop. Additionally, those who need several VMs to experiment with can create them themselves, because they have the 'multiattach' vmdk to work with. Again, I'm out of the loop.

Anyway - What I hear you saying is that once a machine is exported, the multiattach status gets stripped. Therefore, it will *only* import as a 'normal' machine... Correct?

Problem is; I *need* the local HD to be 'multiattach'. There's no way around that! I will try your suggestion of zipping (tar) the files, copying to the user's machine, un-zipping them, settings ownership properties, setting access properties, and then creating the machine (via ssh) using VBoxManage. Sure would be easier to do a simple import. That would save me the copy, unzip, and owner/permission steps...

[mpack]

I personally do not use export/import, so it's possible that I am wrong.

But, as far as I'm aware it has always been the case that disks will be stand alone, never differenced. Therefore all snapshots, linked clones, multiattach disks etc will be merged with their parents during the cloning operation that creates the VMDK. In fact it would be hard to create the VMDK any other way (exported VMDKs can't have a VDI as a parent). If you want to maintain the differencing structure then get used to the fact that copying the VM folder is the only way, and I wouldn't recommend even that - differencing schemes have a nasty habit of breaking.