Search results

I can't reproduce the problem from this thread, so I'm blind currently. Note that my pve-qemu-kvm package 2.9.1-1 is not the same than 2.9.1-1 from proxmox repo. (I have added the patch, but not changed the version number)

I mean, transparent huge can't impact boot. (maybe windows don't like switch between ide-> scsi, I really don't known). Transparent hugepage could impact performance only. BTW, I have build last pve-qemu-kvm with patch for@hansm bug. (which is virtio related, so maybe it could improve...

@wolfgang , you are the master ! :) @hansm : Thanks for helping to debug this !

it's 100% unrelated. Note that if you change disk from ide->scsi, scsi->ide, you need to change boot drive each in vm option.

good to known ! is the difference really big ?

Hi, could you try to disable transparent hugepage on host ? it was disable in proxmox 4 before january 2017, 4.4.x kernel (don't remember exactly which version), and now set to madvise by default echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never >...

does it crash too if you start vm with more than 4g ?

do you have same performance problem, without "--enable-jemalloc" ? we enable it mainly for ceph/librbd performance in qemu 2.4, just wonder if this new commit could change behaviour. this bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1251353 talk about jemalloc, tcmalloc before this...

@hansm which commit ?

virtio-scsi controller (and other scsi controllers), only apply to scsi disks.

Note that in recent kernel (>= 4.7), "discard" mount option is now async, so you can enable it without write penality. (and no more fstrim cron is needed)

you can try to boot on kernel 4.4 from old proxmox, it should works. (just to compare). Which network card do you use ?

hi, do you use same hardware before and after bluestore convertion ? (nvme was used for filestore journal ?)

It's a rocksdb bug with sse4.2 . cephs devs have make a pull request in rocksdb github https://github.com/facebook/rocksdb/pull/2807

for ceph, cache=writeback can improve sequential write (but increase latency for read). you can use discard with ceph && zfs, no problem.

do you have installed the balloon driver before trying to start the service ?

It's impossible to do it in 1 cluster. I think corosync have a hardlimit in code, around 100 nodes. (and this need a lot of tuning of corosync) I never have tested more than 20 nodes. I think the proxmox plan was to be able in the future, in 1 interface, to manage multiple clusters. But...

step 4->6 : use new "qm importdisk" from proxmox5 ;) I'll directly read the vmdk and write it to destination storage (zfs, ceph, ...), without intermediate step.

If it's really a proxmox upgrade bug, I think it can be only 2 thing : qemu version, or kvm version (host kernel module). Maybe can you try to install proxmox 4 pve-qemu-kvm and pve-kernel deb package on your proxmox 5 installation try first with qemu: ----------------------------- wget...

systemctl (status|stop|start) ceph-mon@0 (remplace 0 with id of the monitor , same for ceph-osd, .. )