Search results

I had the same problem, where VMs on NFS storage, qcow2 image, virtio disk would be corrupted when I tried to take a snapshot. In some cases the images were repairable with qemu-img but in other cases I had to restore from backup because the image was so damaged. Nasty bug. This affected only...

I just had a similar thing happen with Proxmox 4.4 - added a new node, and on some (but not all) of the already-existing nodes 'pvecm nodes' showed the new node using its FQDN. Attempts to migrate VMs from a node where the new node was listed using its FQDN failed. I added 2 more nodes and the...

Thanks - excellent info. I'll go back and switch the virtio VMs to scsi next time each needs a reboot. A few percent difference in performance won't be noticeable in my environment and the advantages of scsi are clear.

That's what I've found - this only impacts virtio, not virtio-scsi. I obviously need to read the forums (or the docs) more often - I didn't realize that virtio's time had passed.

I had the impression that virtio was recommended if the VM's OS supports it, so we've been using virtio for CentOS/Ubuntu/Debian VMs until now. I haven't measured the speed with scsi vs virtio, but after going back and forth with some test VMs over the past few days I have the impression that...

That's the plan for new VMs, but we have a bunch that need snapshots when we do updates that are configured for virtio. I tried changing the disk type on one of those to scsi but it wouldn't boot. If there's an easy way to fix that we can go back and change older VMs that use virtio to scsi...

No, it wasn't. I added it just now in one of the test VMs (CentOS 7, virtio disk). Installed on the guest, shut down, enabled via Proxmox gui, restarted. Verified that qemu-guest-agent was running on the guest. Took snapshot, no improvement: Per qemu-img check: 9275 leaked clusters...

After more tests, the corruption that happens to .qcow2 images when making a snapshot involves CentOS 6 and 7 VMs that were set up using virtio disks, when storage is NFS. I can reproduce this 100% of the time - it isn't a subtle bug. Snapshots of CentOS VMs that were set up using scsi as the...

Upgraded: pve-manager/4.4-13/7ea56165 (running kernel: 4.4.49-1-pve) This didn't make a difference: VM 1, CentOS 7, virtio 500 gb qcow2 disk, gets corrupted 100% of the time when I try to take a snapshot. Sample qemu-img check results below. VM 2, CentOS 7, virtio 500 gb qcow2 disk, does...

I'm able to reproduce this, and it isn't a hardware problem. pve-manager/4.4-13/7ea56165 (running kernel: 4.4.44-1-pve), with CentOS 6 and 7 VMs using virtio disk driver, qcow2 images, on NFS (have been able to reproduce reliably on 3 different NFS servers). All is well, then you take a...

I've been consistently running into a similar situation with Proxmox 4.4. Snapshots of VMs that use local-lvm storage always work, but snapshots of VMs that use .qcow2 images on NFS storage often wind up damaging the image, requiring repair with qemu-img. This didn't happen with Proxmox 3.x...

I'm happy to report that this made a GIANT difference here. Not only is disk I/O much better on the CentOS 5 VPSs I converted from IDE to VIRTIO, but backups work as expected with no complaints from CentOS about IDE timeouts. Big relief - this was killing us. We have some old FreeBSD KVM...

After a weekend chained at the computer, I think I've worked this out. We converted both test and production clusters to Prox 2.3, and since doing that, on the production cluster, some KVM guests have been hanging in the middle of the night - not always, maybe 2-3 times/week. The common...

We're having this problem - it only affects CentOS 5.x KVM VPSs, all of which were set up with IDE drives. It does not affect CentOS 6, Ubuntu or Debian, all of which use virtio, and I think this may be a clue. It hits the CenOS 5 KVM guest that's being backed up. Hardware is Dell r710 and...

I hadn't thought of clonezilla as a recovery method. In the corrupted-qcow2-image cases I've got the KVM guests run just fine - it looks like the damage is on the disk image somewhere after the actual data in most cases. I'll give this a try. In the meantime, I wanted to document that vzdump...

I haven't tried mixing 2.2 and 2.3, but I've upgraded my test cluster and the backup is indeed quite different. It's a big improvement (more efficient, doesn't require allocating free space in the VG to avoid running out of room in the snapshot before the backup finishes, works great over NFS)...

Hmmm - I "fixed" the problem by accident. I added a new node (new server, previously unused hostname) to the cluster. That regenerated whatever needed to be regenerated, and now the ghost server does not appear in pvecm nodes or in the GUI. Problem solved until next time I delete a node ;-)

No change - the /etc/pve/.members file was rebuilt, but still shows the removed node (which really is gone). If I try to remove the node again pvecm tells me that it's already gone: root@prox2001:~# pvecm delnode prox2003 node prox2003 does not exist in /etc/pve/cluster.conf grepping for...

What about /etc/pve/.members - that file still lists the deleted node - there's no IP number, it's still counted as a node in the node count - it looks like this: "prox2003": { "id": 4, "online": 0}, That file is write-protected, even from root - is there a safe way to remove this line, and...

No difference. I just ran service pvestatd restart on node 1 again, no change. /Paul