Search results

You need to supply more information than you have. Did you check your backup settings to see that there was no bandwidth limit? https://pve.proxmox.com/wiki/VZDump

The Wiki says to change cache to write back https://pve.proxmox.com/wiki/Storage:_ZFS

You define it as local storage, and just make sure the local folder is located somewhere on the ZFS file system. When you select ZFS VM storage it means a block device called a Zvol which is akin to a .raw or .qcow2 storage, neither of which you can store an ISO on without mounting them first.

The Proxmox installer writes grub boot blocks to all the drives in the pool. Do your zfs drive replacement first, and then re-run the grub installer 'dpkg-reconfigure grub-pc' remembering to select all the drives you want boot blocks on.

I think it's the ZFS labels. I tried zpool labelclear but it wouldn't let me because the drive contained pool info. I don't understand the point of the command in that case.

Is sheepdog up to production quality yet, or still experimental?

Ok, I worked it out, because I moved the drive from SATA to a USB external device, it lost the plot with the device naming. I couldn't get it to replace after trying different tricks for hours. What I had to do was totally zero out the drive with dd if=/dev/zero of=/dev/sdc bs=1M so there was...

I haven't had any luck. I trashed one of my test drives with dd and tried to which gave me the following: root@kvm4:/home# zpool status pool: rpool state: DEGRADED status: One or more devices has been taken offline by the administrator. Sufficient replicas exist for the pool to...

It works fine for me on a machine I only build last week with the latest proxmox 4.0-57 Did you remember to run update-initramfs -u after editing the zfs.conf file? If not then cat /sys/module/zfs/parameters/zfs_arc_max will return 0

This thread says it's not harmful https://github.com/zfsonlinux/zfs/issues/3111

It depends if you mind taking each VM down for a while. The easiest non-cluster migration is to stop the VM, make a backup of it from the proxmox GUI, ftp the backup .lzo to the new server, and use qmrestore to import the backup.

I have two vms with drives in qcow2 format that were created to be 80GB each. Over time they crept up in size. The server is on the current 3.4 but the drives were made years ago on an earlier version, maybe even 3.0 vintage. One is now 104GB, the other 159GB is this normal behavior for qcow2...

So do you create the grub boot partition and run 'dpkg-reconfigure grub-pc' before you run zpool replace?

ZFS needs an SSD read (L2ARC) and write (ZIL) cache to perform well. The CPU usage is most likely the default compression enabled. You need a stack of RAM too for the ARC cache. I tried ZFS on a test system that had only 6GB and the CPU usage went crazy installing the iso for the test VM...

That's good to know. If I have to replace an SSD because one fails, how does the grub boot loader get written to the new drive? I presume the Proxmox installer did it originally.

Try running the Proxmox installer with only one disk attached, see if will let you create a RAIDZ-1 pool, then after everything is installed, attach the other two disks and add them to the pool from the command line.

If I make a Proxmox server running RaidZ with 3 same size SSD drives, is it possible to have grub boot on two of the drives for recovery like you could have in a Raid 1 mirror if you copied the grub boot across? I am not familiar with how RaidZ distributes the redundant data. I am just trying...

I had a similar problem with an Intel chassis last year rebooting Proxmox, after much trial and error it turned out that the power supply was getting a bit tired. Replaced it and all good.

When a forum gets busy, then it's not a sticky threads issue, it usually required the creation of more sub-forums that's all.

I guess you could try installing 3.4 and upgrading it to 4.0