resize on import

[candlerb]

A wish-list/discussion point.

Should the "import" script invoke snf-image-helper if the blockdev size is greater than the imported image size? The tasks it would need to run are:

• 10FixPartitionTable
• 20FilesystemResizeUnmounted

[skalkoto]

My impression is that this is feasible. It is not a top priority right now but it is feasible. We could for example create a mode={create, import} rule in the instructions we give to the helper VM. Then, the helper VM tasks can check the mode they are in and alone decide if they are to run or not.

In *BSD things are rather straight forward, but for other systems there are things that we need to consider:
In Linux, if the last partition is swap, we need to remove it, enlarge the partition before that and then recreate it.
In Windows, the fs resizing is performed in 50FilesystemResizeMounted. In this task we add instructions to sysprep to execute the resizing in the first boot. We could do this in 20FilesystemResizeUnmounted using ntfsresize but this utility marks the NTFS file system as dirty after it runs and the next time Windows boot, a Scandisk will be performed which takes long. I don't think there is an option right now to alter the registry and put the resize instructions there to do it in the next boot. When we are in import mode, the image properties are not available. We don't even know which the root partition is. This leaves us two options:

1. Do it with ntfsresize
2. Leave it as it is. Windows allow live resizing the NTFS partitions. The user can do it from within the VM using diskmgmt.msc

One last thing we really need to consider is this:
Do we wanna allow doing changes in a user's VM? When we deploy an image, the VM's disk is still ours to do whatever we want. When we use gnt-backup, the disk of the VM belongs to the user and it contains personal data.

[candlerb]

When we are in import mode, the image properties are not available

Is that true? I thought that the settings were imported from config.ini and that they'd be made available to the import script. I need to test that though. If it's not true, then IMO it's a bug in Ganeti.

However I had forgotten that snf-image-creator was responsible for removing swap partition, which is more of an issue. It gets fragile if the 'export' script starts messing around with partitions too.

[skalkoto]

Is that true? I thought that the settings were imported from config.ini and that they'd be made available to the import script. I need to test that though. If it's not true, then IMO it's a bug in Ganeti.

If you use the config_url to pass OS parameters, then they are not monitored by ganeti at all. If this is going to cause a problem, maybe we need to reconsider about which os parameters the user can pass though the config_url. For now, I think we can implement this without looking at the img_properties

However I had forgotten that snf-image-creator was responsible for removing swap partition, which is more of an issue. It gets fragile if the 'export' script starts messing around with partitions too.

If the VM's hard disk needs to be altered, then I think the import script will do this on the target disk, not the export script. Since we already need to mess around with partitions in order to enlarge the last partition, there is no problem with removing the swap and recreating it. The problem would be if we had to alter /etc/fstab to update a UUID or something. Then we would have to mount the root partition which we don't know. According to this: https://wiki.archlinux.org/index.php/swap swap partitions can be labeled and have UUID's assigned to them. If this is true then we have to make sure that the label and the UUID of the swap partition remain after the removal and the recreation of the partition.

[candlerb]

You can close this for now if you want. I only raised it because the dump/restore approach taken by instance-debootstrap and instance-image has the advantage that you can change the image size when moving a VM.

I thought that snf-image-helper had much of the infrastructure required to expand an image on import, but if it's difficult then maybe it's not worth the effort.

[skalkoto]

It won't hurt leaving this open. We may fix it in the future.

I'm really thinking that making snf-image-helper capable of auto-detecting the needed image properties is the way to go. At least OSFAMILY and ROOT_PARTITION which are mandatory. Take a look at issue #50.

Another thing I'm giving a thought to is putting a signature somewhere in the hard disk of the VM snf-image deploys. We could put there the configuration parameters it used and do not raise security concerns (like the password property).

Both are premature thoughts, but maybe they could help resolve this.