if you don't have subscroption license, you need to enable the nosubscription repository , and simply do the update online.
https://pve.proxmox.com/wiki/Package_Repositories
(you can configure it though the gui too)
Proxmox VE 7.2 released!
- Thread starter martin
- Start date
https://pve.proxmox.com/wiki/Package_Repositories
(you can configure it though the gui too)
Made the mistake of upgrading, now gpu passthrough is broken. The VM fails to start up with the helpful error message: "failed: got timeout". Basically the same thing is syslog. If I remove the GPU, the boots and runs fine. Add the GPU back as passthrough, fails to start.
Is there any way to find out any real useful info on what is happening besides the "got timeout"?
Is there any way to find out any real useful info on what is happening besides the "got timeout"?
There are multiple similar reports. Booting kernel 5.13 seems to be a work-around. Do you see BAR can't reserve memory errors in the system logs? Do you see BOOTFB in /proc/iomem?
That sounds rather odd, besides keyboard map config, which you probably tried to avoid by using simpler passwords, there's not much besides some disk failure that would stop one from logging in as
root@pam on a default installation. Do you see any errors flash up on boot? Could you verify that the password gets typed in correctly by testing entering it in the username query?
In case no one mentioned it yet: There's a typo in the docs (pceveph instead of pveceph)
thanks for noticing us, fixed in git: https://git.proxmox.com/?p=pve-docs.git;a=commitdiff;h=81de7382b02c0a78a8a1e83bac6b30b39d4baa6b
I am creating a new ceph erasure coded pool using the following command:
Using this I would expect a pool with 2 data chunks and 1 coding chunk.
So that would mean I get a pool that is able to use 66% of my pools space as a sort of raid 5.
But when I look at the storage that is attached to the pool it says 2,22T usable (total pool storage is 6,4T)
In a second attempt I created a pool with 3 data chunks and 1 coding chunk as that should allow for 75% usable space.
And again the storage that was made reports a 2,22T usable.
I see the command creates 2 pools, 1replicated metadata pool (which it attaches the storage to) and 1 data pool with erasure coding.
So am I doing something wrong? Or do I expecting to see incorrect/other numbers then I should be expecting?
Code:
pveceph pool create slow_ceph --erasure-coding k=2,m=1,failure-domain=osdUsing this I would expect a pool with 2 data chunks and 1 coding chunk.
So that would mean I get a pool that is able to use 66% of my pools space as a sort of raid 5.
But when I look at the storage that is attached to the pool it says 2,22T usable (total pool storage is 6,4T)
In a second attempt I created a pool with 3 data chunks and 1 coding chunk as that should allow for 75% usable space.
And again the storage that was made reports a 2,22T usable.
I see the command creates 2 pools, 1replicated metadata pool (which it attaches the storage to) and 1 data pool with erasure coding.
So am I doing something wrong? Or do I expecting to see incorrect/other numbers then I should be expecting?
@Thaillie:
You are not alone with this confusion. I have created a ec pool for testing the new features, too.
I have written a lot of test-data to the pool and was confused that the usage of the storage remains at 0.00% (101KB).
I think maybe the data on the summary shows the metrics of the metadata pool instead of the data pool. However the data is written without problems to the data pool and i can access it without problems. The usage of the pool is growing when writing data (i can see at the pools overview).
Can anyone confirm this behaviour?
You are not alone with this confusion. I have created a ec pool for testing the new features, too.
I have written a lot of test-data to the pool and was confused that the usage of the storage remains at 0.00% (101KB).
I think maybe the data on the summary shows the metrics of the metadata pool instead of the data pool. However the data is written without problems to the data pool and i can access it without problems. The usage of the pool is growing when writing data (i can see at the pools overview).
Can anyone confirm this behaviour?
I can see v7.2-3 in my console but I cannot see the VMID Range under Datacentere > Options. Last available option is still "Maximal Workers/Bulk action".
I also cannot see VirGL as an display option, only VirtIO-GPU and all the usual ones.
Here are my package versions:
I also cannot see VirGL as an display option, only VirtIO-GPU and all the usual ones.
Here are my package versions:
Code:
proxmox-ve: 7.2-1 (running kernel: 5.15.35-1-pve)
pve-manager: 7.2-3 (running version: 7.2-3/c743d6c1)
pve-kernel-5.15: 7.2-3
pve-kernel-helper: 7.2-3
pve-kernel-5.13: 7.1-9
pve-kernel-5.15.35-1-pve: 5.15.35-2
pve-kernel-5.13.19-6-pve: 5.13.19-15
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 15.2.15-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.2
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-8
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-6
libpve-guest-common-perl: 4.1-2
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.2-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.12-1
lxcfs: 4.0.12-pve1
novnc-pve: 1.3.0-3
proxmox-backup-client: 2.1.8-1
proxmox-backup-file-restore: 2.1.8-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-10
pve-cluster: 7.2-1
pve-container: 4.2-1
pve-docs: 7.2-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.4-2
pve-ha-manager: 3.3-4
pve-i18n: 2.7-1
pve-qemu-kvm: 6.2.0-5
pve-xtermjs: 4.16.0-1
qemu-server: 7.2-2
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.7.1~bpo11+1
vncterm: 1.7-1
zfsutils-linux: 2.1.4-pve1
Last edited:
Besides the fact that we refer to the b(eta) version in the release notes: Why does that matter? The old "stable" version, not touched for years, is broken pretty much everywhere, BIOS and UEFI tests failed all, and the new rewrite, while maybe marked as beta, worked in all our tests on quite some hosts from DDR3 to DDR5 and virtual, which the old version couldn't even do. This is a memory test, not a file system or other software that can possibly eat one's data, it just needs to work, which this does and the previous didn't anymore on any just somewhat recent system. Beta is just a label, in the end the stable version, once released, is still under a no liability open source license anyway. If you actually require support for our software stack the only way that guarantees anything is to buy a support subscription, otherwise it's just best effort.
Last edited:
We are seen issues like this too (as reported in pve-user ML). We also have ceph. Issue is easily reproduced with bulk migrations.
We are trying downgrading pve-kvm-qemu and qemu-server (downgrading the former only didn't work)
Having some issues with the screen not working during installation on Dell R610 server. I've tried this with 4 different monitors at our data center, but was successful with Dell R630. It appears that the screen dimensions during installation (after the initial Proxmox installation choice screen, and then the windowed CLI screen that shows after it) blanks during installation, with the monitor stating that the screen dimensions are not compatible with the monitor. The monitors are typical 19" and 24" 4:3 and 16:9 ratio. I realize this may be something to do with the older servers, but what can be done to allow this installation to be completed?
P.S. Was able to install PVE 6 on that box just fine. Definitely something different in PVE 7.
P.S. Was able to install PVE 6 on that box just fine. Definitely something different in PVE 7.