Bug 1164852

AFAIR, this image contains some information that is needed for vdsm when the vm starts, one of the things i remember is vm uptime to be reported correctly..

AFAIU from the description this is not related to RAM volume, the general snapshot flow creates config volume, regardless if it's live or not or live+RAM

moving to storage

There's seem to be a misunderstanding regarding this bug and it's totally my fault, the description is very unclear, so I'll re-describe:
During the creation of live snapshot with ram enabled on a VM, 2 new images are created (besides the data snapshot) one of them (configuration image) is totally redundant after this operation is over, one can even delete it and nothing will happen.

During a live snapshot, ram snapshot disabled, one volume is added to each image vol-chain and no new and redundant images are created.

btw on block Domains, a configuration image size is 1G while the actual data written on the volume is lower than 1k.

(In reply to Michal Skrivanek from comment #3)
> AFAIU from the description this is not related to RAM volume, the general
> snapshot flow creates config volume, regardless if it's live or not or
> live+RAM
No, this is not true.
The config volume is created only if the memory volume is created. They are coupled by the builder:

    private MemoryImageBuilder createMemoryImageBuilder() {
        if (!isMemorySnapshotSupported()) {
            return new NullableMemoryImageBuilder();
        }

        if (getParameters().getSnapshotType() == SnapshotType.STATELESS) {
            return new StatelessSnapshotMemoryImageBuilder(getVm());
        }

        if (getParameters().isSaveMemory() && isLiveSnapshotApplicable()) {
            return new LiveSnapshotMemoryImageBuilder(getVm(), cachedStorageDomainId, getStoragePool(), this);
        }

        return new NullableMemoryImageBuilder();
    }

The storage layer has no need for the config volume. Michal, I think this should be returned to virt.
Can you confirm?

yeah
any suggestion where to store it? snapshot volume's metadata? ovf?

(In reply to Michal Skrivanek from comment #6)
> yeah
> any suggestion where to store it? snapshot volume's metadata? ovf?
It's already stored in the database in the "snapshots" table, "vm_configuration" column.
Isn't that enough?

*** Bug 1185499 has been marked as a duplicate of this bug. ***

Moving to review for 3.6.  re: Comment 7, What happens in the event a user decides to move a volume to a new Datacenter, possibly in a new Manager instance?  If we move the config data off the volume and into the DB, it will not follow the VM in that case.  Can we investigate using a significantly smaller size, and storage mechanism that will follow the VM?

(In reply to Scott Herold from comment #9)
> What happens in the event a user
> decides to move a volume to a new Datacenter, 
There is no API to manipulate these volumes. Implementing bug 1150239 should allow regular volume manipulation verbs on these volumes too, but in any event there isn't, and won't be, any API to move volumes between DCs.

> possibly in a new Manager instance?
The only feasable way do this is to detach the domain and import it to another engine. In this case, all the snapshots info should be in the OVF_STORE volume anyway, so it's still redundant.

> If we move the config data off the volume and into the DB, it
> will not follow the VM in that case.  
It will - see above. Moreover, the OVF_STORE will have this info on EVERY domain associated to the VM, as opposed to the current conf volume which only exists on one domain.

> Can we investigate using a
> significantly smaller size, and storage mechanism that will follow the VM?
Just kill this, and rely on the database and its mirror in the OVF_STORE - see details above.

Removing from 3.6 due to capacity

we could reconstruct the VM params from the OVF_STORE indeed

This will not make it in a reasonable time. Please re-open if you still feel this should be fixed