Hi, this is a 'little detail' but slightly irksome, so I'm posting to ask if anyone knows 'probable cause' or 'possibly resolution'.
Context: I'm helping a research project setup some servers in the past month / and ongoing.
The dev server was setup last month, and is running ProxVE 1.9 (since 2.0 final wasn't yet released..)
The new 'production' server was setup this week, is running ProxVE 2.0
On the ProxVE 1.9 host I setup a KVM based VM, clean install of Ubuntu Server LTS, tweaked as per project requirements; then did a vzdump and qemurestore to roll out 5 identical VMs. (ie, changed the IP and Mac address in the clones, but not much else)
I just repeated this exercise on the new ProxVE 2.0 host: Brought over the same TGZ dumpfile from the Dev Server; used web interface to restore it (cmd line restore has issues currently I gather) -- then adjusted config for the new network environment; updated it. For a lark - I took a backup of the VM, command line, first using lzo compression and then with Gzip.
The original archive that had been prepared on the ProxVE1.9 host was approx 325megs on disk (.tgz file type)
After the first vzdump finished (LZO compressed) the dump file was approx 1.6gbs on disk. Humm.
Tried the next vzdump with gzip compression - the dump file was approx 6.6 gigs on disk. Yipes.
Note that the VM does have a 200gb "thin provisioned" (ie, mostly empty) disk image. I think the updates I ran inside the Ubuntu VM server downloaded no more than 50-60megs of new packages. The disk footprint is still very tiny inside the VM.
So I'm a bit baffled, why the vzdump files are so drastically much larger for a VM which hasn't had significant size change. It suggests to me ?some change in how proxve dump behavior? is working from 1.9 to 2.0 but I'm not sure ..
-- handling of sparse data ?
-- some other obvious answer I'm missing ?
At the end of the day, it is not a big problem. More a modest concern. It was also slightly frustrating, the dump took 'a long time' (1 hour) - in the past I thought sparse VM images were processed a bit more quickly than this for backups.
Any thoughts:comments are certainly greatly appreciated.
Thanks,
Tim Chipman
Fortech I.T. Solutions
http://FortechITSolutions.ca
Context: I'm helping a research project setup some servers in the past month / and ongoing.
The dev server was setup last month, and is running ProxVE 1.9 (since 2.0 final wasn't yet released..)
The new 'production' server was setup this week, is running ProxVE 2.0
On the ProxVE 1.9 host I setup a KVM based VM, clean install of Ubuntu Server LTS, tweaked as per project requirements; then did a vzdump and qemurestore to roll out 5 identical VMs. (ie, changed the IP and Mac address in the clones, but not much else)
I just repeated this exercise on the new ProxVE 2.0 host: Brought over the same TGZ dumpfile from the Dev Server; used web interface to restore it (cmd line restore has issues currently I gather) -- then adjusted config for the new network environment; updated it. For a lark - I took a backup of the VM, command line, first using lzo compression and then with Gzip.
The original archive that had been prepared on the ProxVE1.9 host was approx 325megs on disk (.tgz file type)
After the first vzdump finished (LZO compressed) the dump file was approx 1.6gbs on disk. Humm.
Tried the next vzdump with gzip compression - the dump file was approx 6.6 gigs on disk. Yipes.
Note that the VM does have a 200gb "thin provisioned" (ie, mostly empty) disk image. I think the updates I ran inside the Ubuntu VM server downloaded no more than 50-60megs of new packages. The disk footprint is still very tiny inside the VM.
So I'm a bit baffled, why the vzdump files are so drastically much larger for a VM which hasn't had significant size change. It suggests to me ?some change in how proxve dump behavior? is working from 1.9 to 2.0 but I'm not sure ..
-- handling of sparse data ?
-- some other obvious answer I'm missing ?
At the end of the day, it is not a big problem. More a modest concern. It was also slightly frustrating, the dump took 'a long time' (1 hour) - in the past I thought sparse VM images were processed a bit more quickly than this for backups.
Any thoughts:comments are certainly greatly appreciated.
Thanks,
Tim Chipman
Fortech I.T. Solutions
http://FortechITSolutions.ca
