Debian 9 "Stretch" has been officially released. I hope PVE 5.0 will follow soon...
Proxmox VE 5.0 beta2 released!
- Thread starter martin
- Start date
Of course, everybody wants it asap ... The proxmox team is working really hard https://git.proxmox.com/?o=age . So, let's follow Debian's philosophy https://wiki.debian.org/ReleaseWhenReady
Does Proxmox VE 5.0 beta 2 finally support Intel's GVT-D or KVMGT?
according to
https://01.org/igvt-g/blogs/wangbo85/2017/intel-gvt-g-kvmgt-public-release-q42016
How do I use GVT-g in PVE 5.0 beta 2?
I can see kvmgt.ko @
how do I add following of the switch/option to windows guest vm?
-vgt -vga vgt -vgt_high_gm_sz 384 -vgt_fence_sz 4 -vgt_low_gm_sz 128
according to
https://01.org/igvt-g/blogs/wangbo85/2017/intel-gvt-g-kvmgt-public-release-q42016
How do I use GVT-g in PVE 5.0 beta 2?
I can see kvmgt.ko @
Code:
/lib/modules/4.10.15-1-pve/kernel/drivers/gpu/drm/i915/gvt/kvmgt.kohow do I add following of the switch/option to windows guest vm?
Code:
qemu-system-x86_64 -m 2048 -smp 4 -M pc -name VM1 -hda /home/img/win7-64-base.img -enable-kvm -net nic -net tap,script=/etc/qemu-ifup -vgt -vga vgt -machine kernel_irqchip=on -vgt_high_gm_sz 384 -vgt_fence_sz 4 -vgt_low_gm_sz 128 -cpu host -net nic,model=e1000,macaddr=00:DE:EF:12:34:5C –cdrom /home/img/win7-64.iso
Last edited:
well we have not integrated anything yet, but the basic pieces are there
this only works with the kvmgt fork of qemu at https://github.com/01org/KVMGT-qemu not with upstream
i tested it here a bit, but ran into several problems (journal running full of errors, hangs/crashes)
i followed the following site and it mostly worked
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide
i just ignored all the compile steps and added the
Code:
-device vfio-pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/<UUID>,rombar=0edit: typo
according to https://01.org/igvt-g/blogs/wangbo85/2017/gvt-g-upstream-status-update-were-transition-phase
“Upstream” version GVT-g
First public release date Feb. 2017
Last public release date ---
First Version
Kernel: 4.10
Xen: 4.7
QEMU: 2.8.50
I thought Kernel 4.10 already has kvmgt and qemu 2.9 already has gvt-g codes
“Upstream” version GVT-g
First public release date Feb. 2017
Last public release date ---
First Version
Kernel: 4.10
Xen: 4.7
QEMU: 2.8.50
I thought Kernel 4.10 already has kvmgt and qemu 2.9 already has gvt-g codes
it has (it "works" too, see the link in my previous post), but the special "vgt" device in qemu is not upstream (i only found it in the kvmgt fork)
see:
https://github.com/01org/KVMGT-qemu/blob/master/hw/display/vga-vgt.c
but not there in upstream qemu:
http://git.qemu.org/?p=qemu.git;a=t...5a52d2d03ba0081bf98f4b6a;hb=refs/heads/master
I have tried to create a VM using one of the turnkey templates with the following error:
Are these templates only for PVE 4.x, or am I doing something wrong?
Code:
extracting archive '/var/lib/vz/template/cache/debian-8-turnkey-fileserver_14.1-1_amd64.tar.gz'
tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted
tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted
Total bytes read: 497704960 (475MiB, 101MiB/s)
tar: Exiting with failure status due to previous errors
TASK ERROR: command 'lxc-usernsexec -m u:0:100000:65536 -m g:0:100000:65536 -- tar xpf /var/lib/vz/template/cache/debian-8-turnkey-fileserver_14.1-1_amd64.tar.gz --totals --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-xattr-write' -C /var/lib/lxc/101/rootfs --skip-old-files --anchored --exclude './dev/*'' failed: exit code 2Are these templates only for PVE 4.x, or am I doing something wrong?
Yes, I meant LXC container, not full VM (they're all VMs to me, just with different approaches and limitations).
I have indeed tried to set it up as unprivileged. Can you tell me briefly why they have to be privileged, or if it's too much to get into in this thread, point me to some online resources where I can read about this?
Thank you.
Just installed new PVE 5.0 beta2 cluster with Ceph storage. Works good.
You may want add in pveceph deploy scripts 'caps mgr = "allow *"' to client.admin keyring to adapt it to Ceph Luminous, as stated in this bugreport tracker.ceph.com/issues/20296. It permits using 'ceph pg' commands.
And maybe add optional second network to '-network' option of 'pveceph init' command. According to documentation it is a good practice to separate cluster and public Ceph traffic (docs.ceph.com/docs/master/rados/configuration/network-config-ref/).
You may want add in pveceph deploy scripts 'caps mgr = "allow *"' to client.admin keyring to adapt it to Ceph Luminous, as stated in this bugreport tracker.ceph.com/issues/20296. It permits using 'ceph pg' commands.
And maybe add optional second network to '-network' option of 'pveceph init' command. According to documentation it is a good practice to separate cluster and public Ceph traffic (docs.ceph.com/docs/master/rados/configuration/network-config-ref/).
I never ran into this problem?
that might make sense - please file an enhancement request at bugzilla.proxmox.com
It is easy to reproduce. Just deploy PVE 5.0 and Ceph server 12.03 by official Proxmox tutorial or video tutorial and run "ceph pg dump". You will reseive error "Error EACCES: access denied"
did it, Bug 1430
After clean install with "pveceph init" it didn't work, bacause admin caps were
Code:
client.admin
key: c29tZWtleXNvbWVrZXlzb21la2V5c29tZWtleQo=
auid: 0
caps: [mds] allow
caps: [mon] allow *
caps: [osd] allow *For me 'ceph pg' started to work only after changing permissions:
Code:
ceph auth caps client.admin osd 'allow *' mon 'allow *' mds 'allow' mgr 'allow *'Updated:
BTW problem is in file /usr/share/perl5/PVE/API2/Ceph.pm
Code:
896 run_command("ceph-authtool $pve_mon_key_path.tmp -n client.admin --set-uid=0 " .
897 "--cap mds 'allow' " .
898 "--cap osd 'allow *' " .
899 "--cap mon 'allow *'");
Last edited:
Waiting for it too. But let's not be too hasty. Better later and rock-stable...
I hope PVE 5.0 "final" will include the latest Intel microcode update (although Debian can not include it in installation medium due to licensing issues). Nearly all Skylake/Kabylake CPUs (incl. xeon E3) have bug in hyperthreading which can lead to serious problems, i.e. data corruption/loss...
Hi,
I just bought a new rig for use with PVE.
The specs are:
I'm having problems installing PVE 5.0b2 on my NVMe drive (PVE 4.4 installs fine on this drive).
Those are the problems the installers having trying to install on this drive:
Standard install:
Debug install:
I can install PVE 5.5b2 on the ADATA drive, but that's not the OS drive.
Any help ?
I just bought a new rig for use with PVE.
The specs are:
I'm having problems installing PVE 5.0b2 on my NVMe drive (PVE 4.4 installs fine on this drive).
Those are the problems the installers having trying to install on this drive:
Standard install:
Debug install:
I can install PVE 5.5b2 on the ADATA drive, but that's not the OS drive.
Any help ?
Do you have already installed the latest firmware 2.50.
New CPU series have bugs so it is essential to update the microcode frequently.
If you have already the latest firmware, you can try the debian microcode package to update the code.
https://wiki.debian.org/Microcode#Debian_9_.22Stretch.22_.28stable.29
New CPU series have bugs so it is essential to update the microcode frequently.
If you have already the latest firmware, you can try the debian microcode package to update the code.
https://wiki.debian.org/Microcode#Debian_9_.22Stretch.22_.28stable.29