Search results

As LnxBill said previously, PVE provides IAAS, which mean the end unit you manage with PVE are *virtualized OSs*, with a state. With Docker the end unit you manage is *a stateless applications* which is a different scope. Both LXC and Docker are both called *Containers* because they use the...

Your hardware is sending on NMI from this screenshot (reason 39) Try if you can find from out, maybe in your BIOS/Fimware if this was logged, and the reason of that.

> Partition Table: unknown it looks like this img file is not bootable you probably need to reinstall the VM

Anything that qemu-img is able to read.

If you manage to get a disk image from Xen , remember you can use qm importdisk (see qm help importdisk) If you have a OVF you can use qm importovf (see qm help importdisk) For Xen HVM domUs the disk image method should work. For Xen PV domUs, YMMV, if you only have a partition you need to...

Hi Luca Probably you're using multipath and you need a way to multipath daemon ti rescan the the underlying block device since they have changed. Check the multipath documentation this is not PVE specific here. YMMV, but I disabled multipath in my testlab because it was causing me more...

A backup in snapshot mode will slow down the I/O on the VM while the backup is running, but not to point that it should vause HTTP timeouts on web services running on it. For this to debug, please send the VM config: qm config <my_vmid> Also have a look inside the VM /var/log/kern.log for...

Please post your VM config and the exact timeout message on the VM.

On the raw images ( not converted ) check if you have at least a partition table: parted path_to_my_raw print BTW where did you get these .img files from ? We only have .raw and .qcow2 in pve.

poweroff the VM with stop and start again if this does not work, your qcow2 image might be corrupted

Settings in the firewall should not have any effect on the transfer speed. I can't understand why the VM is so slow when acting as the iperf server, these speeds should bye symetrical. Try to run the iperf server on the PVE host, to rule out if this is is a network problem or a VM problem (...

thanks, a video ist worth a thousand words in this case either your VM has no disks (check that in Hardware) or its boot device is not set to the hardisk (check that in Option -> Boot order)

In dem fall wurde ich einfach PVE in einem kleinem SSD neu installieren.

Basically we advice the use of our integrated backup tool vzdump for such operations( you backup the VMs to an external storage, then restore them) , but copying the disk images should be fine too.

> Any idea why this node would have the I/O issue when the storage is still accessible from other nodes? I suppose these device files ( /dev/sd*) refer to ISCSI luns. Propabably a network hiccup between your PVE host and the ISCSI target. Check that you're still logged in your ISCSI session...

> Mich stört der permanente HDD Zugriff alle 2-3 Sekunden, obwohl keine VM und nur lediglich PVE läuft. Der PVE-system logt regelmäßig im Systemlog (/var/log/*) seine Aktivität, ein solche Verhältnis ist zu erwarten von den meisten Betriebsystemen.

If you want to resctrict brute force attacks, a simple alternative would be to restrict the IPs which are allowed to connect on the 8006 port, using the built in firewall.

please try to make a gif video of the VM console, so we see what's happening

First you should try to do a network thoughput by running iperf, the network performance testing tool * on your other machine start iperf in server mode ( -s switch) * on your VM iperf in client mode, connecting to the other machine ( -c switcht)

the pull request was applied, so probably the next realease of proxmoxer will have this fixed