Search results

You probably have to zero out the empty space within the VM before it will compress well. http://forum.proxmox.com/threads/8976-Too-large-size-of-a-backup-copy-Why

Have you tried enabling IOMMU in the bios?

LizardFS gets positive reviews for performance, features, and stability, however I haven't been able to find much documentation on it yet. LizardFS was based on MooseFS when it went open source back in May 2008, I believe the documentation for MooseFS is applicable. I don't know the reason why...

Corosync seems to be trouble for a lot of people, mulitcast is at the center of the problems. I couldn't get it stable myself, and am looking for another way to do clustering without multicast. Some people run corosync in unicast but I couldn't find the info to get that working either. I...

Over provisioning is normally done at the filesystem level, not at the volume management. Try using the zfs quotas to tune the behavior the way you want for each zfs dataset.

I suggest you aquatint yourself with the typical performance for you hard drives first, otherwise you might just be looking at cache effects. Probably better to use a real world transfer not /dev/null and /dev/zero or a proper i/o benchmark program.

virsh in not part of Proxmox, so you must have installed it, did you install it, which packages did you download, did you miss something?

There is no real consensus, you have to examine what the ARC is using the RAM for an work out your settings based on that. This blog explains how http://www.cuddletech.com/blog/pivot/entry.php?id=979

update-initramfs -u doesn't do anything until you reboot after it, it's a modification to the boot ram disk.

Sounds about right, ZFS will use half your RAM for ARC unless you tell it not to. Proxmox will use about 1GB for it's various processes.

That's normal, you have to remount the fuse file system in local mode to make changes. https://pve.proxmox.com/wiki/Proxmox_Cluster_file_system_%28pmxcfs%29#Recovery

I don't think it's an addon package, looks to be part of the debian systemd install. You might be able to disable it, though when I do a service --status-all it doesn't appear to be listed.

Did you eventually manage to speed up the process? I am keen to try something similar with zfs.

When you say the hard drive is 350GB do you mean as viewed from inside the guest OS, or somewhere in Proxmox? Where are you seeing this number?

corosync is already part of pve, at a guess I would say there was a conflict having both of them. Try removing corosync and putting back corosync-pve libpve-access-control librados2-perl proxmox-ve pve-cluster pve-container pve-firewall pve-ha-manager pve-manager qemu-server

Unfortunately I didn't know multicast was essential for corosync. The gigabit switch I used for the cluster was un-managed, so no chance of accidentally blocking multicast, and two of the three Proxmox nodes did cluster, but I kept getting the "Permission denied - invalid ticket 401" stuff...

So in order of events. Use dd or a windows equiv in the guest OS to zero out the free space, and delete the big file it created as per my previous post. Stop the VM and convert the disk image to .raw convert the .raw back to .qcow2. Make sure there are no snapshots before you do all that...

Try qemu-img convert -O raw image.qcow2_backup image.raw and see what size it comes out as. Then convert it back to qcow2 Another trick is to zero out the free space in the guest OS by creating a big empty file. eg. if it's a linux guest, and /home has 50GB free then do something like: dd...

I had similar problems this week, not found the cause yet, possible multicast issues. It got so bad I had to reformat 3 nodes, and completely remove all signs of the cluster. Not the ideal situation, I was looking at implementing live migration, but without a cluster that's hard to do, not...

IP assignment is usually a function of the guest OS not the host.