[pve-devel] kvm disk template implementation ideas

[Dietmar Maurer]

> >>maybe it is enough if we can get the import/export command for a
> storage:
> >>
> >>sub export_command {
> >>my $volid = shift;
> >>
> >>return ['dd', 'if=$volid", 'of=-'];
> >>}
> 
> >>What do you think? With that you can create command pipes.
> 
> Yes, I think it's good idea.
> But do you need to use that for by example a export/import between 2 local
> dir ?  (cp is more simple in this case)

We can add special case optimization when needed. Should not be a problem.

> >>Well, I do not want to support such kind of clone now (base image) -
> >>that creates too many problems for me.
> >>
> >>There are 'internal' and 'external' snapshots. External snapshots
> >>(base image) are problematic because you need to track that external
> >>file. I can see many problems regarding VM snapshots with that.
> 
> I don't know for other storage, but nexenta by example, can't delete the base
> image if clones exists.
> 
> >>So before we think about such feature, we need to implement VM
> snapshot support.
> >>Already thought about that?
> 
> implement snapshot function by itself it's easy for some
> storage(sheepdog,nexenta,rbd soon).
> I can't tell for lvm.

Easy is maybe the wrong term ;-) Our VMs use several disks, and each disk can have
other storage type, and some storage types only support snapshots indirectly with
the help of lvm. Some storage types supports different kind of snapshots (internal or external)
...
 
> Do we need to register in the vm config files the snapshots list ? Or
> implement a snapshot listing sub which scan the storage and display the
> snapshots for disk?

A simply storage scan does not work, because we also want a snapshot of 
the VM configuration!

My idea was to extend the <vmid>.conf file to include a copy of the config
for each snapshot:

----START----
# The current config is on top
mem: 1024
parent: snap2

[snap3]
mem: 512
parent: snap1

[snap2]
mem:128
parent: snap1

[snap1]
mem: 256
----END----