Export Virtual Machine in qcow2 format.

[Andrea Carnevali]

Hello,
I should export a virtual machine running in proxmox (version 5.3.12) to do a test and run it on a centos distribution with KVM.
In my old installation of proxmox I found the file of my virtual machine inside the folder /var/lib/vz but with the new version I think the file of the vm isn't present. This is right?
What is the correct way to do it?

thanks a lot

Andrew

 

[t.lamprecht]

You can still save them to local (not local-lvm) and have the qcow2 file there, but we now create a thin LVM as then one can do cheap snapshots, and a few other advantages so you probably installed the VM with its disk there.

Anyway, you should be able to see where the VM disk resides through the VMs hardware view, or checking it's config (qm config VMID) on the shell..

With the Volume ID you can then get the path as seen from the host OS to the image and use qemu-img convert to produce a qcow2, e.g.:

pvesm path VOLUME-ID
qemu-img convert -O qcow2 -f raw INPUT-PATH  OUTPUT.qcow2

 

[Andrea Carnevali]

Thanks for your fast replay.
Now I can convert my VM.

Andrea

 

[promoxer]

pvesm path VOLUME-ID
qemu-img convert -O qcow2 -f raw INPUT-PATH  OUTPUT.qcow2

@t.lamprecht will qemu-img produce a consistent qcow2 if executed while the VM is running? Thanks!

 

[LnxBil]

@t.lamprecht will qemu-img produce a consistent qcow2 if executed while the VM is running? Thanks!

Why would you do that? Of course is it not consistent, it NEVER is unless the VM is powered down.

 

[promoxer]

I want to backup a disk by itself. How does vzbackup make it consistent then?

 

[LnxBil]

I want to backup a disk by itself. How does vzbackup make it consistent then?

It does not. It is only crash-consistent.

You may get more consistency if your guest is able to know that it is going to be backuped up and has built-in features for online backup, e.g. a database or a filesystem. This has to be implemented on the guest side and can then be hooked into the qemu guest agent fssfreeze-hook to make it more consistent. This is what gets triggered in vzdump via QEMU agent.

Everyone that says that their solution is consistent lies to you. Consistency is VERY hard to archieve and relies on os and application features.

 

[promoxer]

hang on, i'm on ZFS, are you saying that vma.zst files produced by vzdump is not based on a single point in time, aka consistent?

Could you define "crash-consistent"?

 

[LnxBil]

hang on, i'm on ZFS, are you saying that vma.zst files produced by vzdump is not based on a single point in time, aka consistent?

Of course not. How should that be possible? The hypervisor does not know the status of the VM and to get at-least a storage consisten snapshot, you would need the data in memory as well ... please read up on this topic, this is how computers work ... have been and always will be. Everything is relative to the assumptions you have and consistency is always for the worst case. It may be, that you will have consistent backups, but this is NOT the norm.

Example:
If you have a fileserver and backup up files at night, where no one is working and no background tasks are running, the chances of having a consistent filesystem state are very high, but if you backup a database that has a very high transaction throughput, you will only have crash-consistency (also with respect to the database) unless you hook into the database and transform it into backup mode before the in-memory disk snapshot and release it afterwards. This is application-consistency.

Could you define "crash-consistent"?

First hit on google. Application-consistens is what I talked about with the qemu hook.

 

[fabian]

hang on, i'm on ZFS, are you saying that vma.zst files produced by vzdump is not based on a single point in time, aka consistent?

Could you define "crash-consistent"?

it will always be "point in time" in the sense of "backup consists of what was persisted to disk at time X".

the details depend on the backup mode - for VMs, with
- mode stop, the VM was shutdown, so applications that behave properly on shutdown will have persisted all their state/data (most consistent)
- mode suspend, the VM was suspended
- mode snapshot, the VM uses qemu-internal snapshotting to create the point-in-time (this is not a storage snapshot!)

for the latter two modes, consistency can be improved with help of the guest OS and qemu agent - the fsfreeze command is then executed before suspending/snapshotting, so that applications that support this can trigger their own logic to flush their in-memory data/..

in all modes, writes after the backup has started are handled in a way that ensures that the old data is backed up before incoming writes overwrite it (this is what gives it "point in time" semantics). that is also the reason why a slow backup target can hurt your VM performance (it's basically copy-to-backup-before-write).

 

[promoxer]

it will always be "point in time" in the sense of "backup consists of what was persisted to disk at time X".

well, that seems to gel with my layman definition of "point in time" being: the backup's view of the storage stays the same from start til end of backup and that is good enough for me.

But I'm confused by "not a storage snapshot", did you mean it should not be confused with "Snapshot" function found in VMs?

 

[fabian]

it doesn't use any "snapshot" features of the storage layer (like ZFS, or qcow2, or LVM-Thin), the snapshot is purely within Qemu (since Qemu sits between the guest and the storage layer, it can intercept the guest writes and ensure data gets backed up before it's overwritten by the guest). for containers this is different, snapshot mode there actually requires and uses snapshots on the storage layer.

 

[promoxer]

it will always be "point in time" in the sense of "backup consists of what was persisted to disk at time X".

qemu-img convert -O qcow2 -f raw INPUT-PATH  OUTPUT.qcow2

Ok, thanks, so... if I start this command at 9 pm and it finishes at 9:05 pm, only data that is on disk at 9pm will be saved. Anything from 9:00:01 and onwards won't be in the OUTPUT.qcow2, correct?

 

[LnxBil]

qemu-img convert -O qcow2 -f raw INPUT-PATH  OUTPUT.qcow2

Ok, thanks, so... if I start this command at 9 pm and it finishes at 9:05 pm, only data that is on disk at 9pm will be saved. Anything from 9:00:01 and onwards won't be in the OUTPUT.qcow2, correct?

No, this a file copy, not the backup mechanism of PVE itself, which snapshots in memory. If you want to copy the files yourself, you need a storage snapshot.

 

[fabian]

Like @LnxBil says, if you copy a file (and this is all qemu-img convert does - read from one file (descriptor) and write to another, possibly converting the format along the way) there is nothing ensuring nobody else doesn't change the file at the same time, and if some part that hasn't been copied yet is changed, then the copy will be inconsistent. you can make the file immutable, but then no writes are possible at all. vzdump (for VMs) uses Qemu's internal mechanisms to ensure that no guest writes being done after the backup has started end up in the backup, while still allowing writes to happen. vzdump for containers use a different approach (either with more downtime, or with storage support).

 

[promoxer]

Yes, I understand copy does not have a lock on the disk.
I see zfs checkpoint, can it be used to lock and copy a disk?

 

[fabian]

no, that is something else entirely (also, it's zpool checkpoint. I am not sure what problem you are trying to solve, maybe we should start there?

 

[promoxer]

Oh yes, `zpool checkpoint`. Problem is, I want to backup 1 disk only by itself while the VM is running.

 

[LnxBil]

Oh yes, zpool checkout. Problem is, I want to backup 1 disk only by itself while the VM is running.

Then to it from within the VM with guest OS backup tools.


So to sum the PVE part up:
- use vzdump to create a backup with QEMU guest agent inside of the VM and configure your application consistence accondingly (please refer to the manual of the application inside of your VM) and you MAY have a consistent state
- shutdown the VM and backup whatever you want in a consitent state

You can also run with ZFS, do the QEMU agent application consistency stuff manually and do a ZFS snapshot and send/receive them to your backup destination.

 

[fabian]

you can simple configure the VM to only have that disk included in the backup, and run vzdump?