Search results

Not sure what happened, but creating a VM and changing it to OVMF bios now renders it unable to boot from the CD ROM. If I change it back to SeaBIOS it will boot the CD ROM again. After I create the VM I add an EFI disk. At first boot I dump out to the shell. If I go into the BIOS and...

Having received no response here or on a couple of relevant mailing lists, I've started from scratch, and I'm attempting to see what the minimum I can do to trigger the problem. I've confirmed that it still works when the host and the VMs are all on the same disk, even if that disk is just a...

(With the caveat that I realize this is clearly not supported.) That was not the end of my months long struggle with vfio/iommu :D It turns out that ZFS is not the problem. It seems the only way I can multi-seat to work is by having the OS and the VMs on a single disk. I've tried MDADM with...

I had to reinstalled the system, and it worked. All I had to do was enable kdump in /etc/default/kdump-tools, and enable 256M of ram for the dumps in /etc/default/grub, then updated-grub. Something I did must have been preventing this from working in the previous installation.

Thanks for the reply guys. I was actually looking into cephs earlier. I have minimal experience with gluster, but none with cephs, so I may learn something as an added bonus. I may end up ditching ZFS all together on the test server. I run some VMs with GPU passthrough, and ZFS seems to...

I may have solved this. I (1) reinstalled the node (2) without ZFS and (3) the VMs with NUMA enabled. One or a combination of those three things likely solved my issue. The problem did follow me to the other node, so I'm fairly certain this is a reproducible problem if I set up a node the...

I just said "locally" to distinguish from pve-zsync, which would involve a remote server. I see what you mean. It seems like I could do the inverse: create glusterfs on top of ZFS. I have the node set up, and I'll hopefully get a chance to experiment later today. I'm wondering if I could...

I wanted to set up HA locally, but I also wanted to try to use PVE-zsync with my remote DPS. Can you elaborate as to why it won't work? I see documentation like here and anecdotes like this one from PM forums, and I wonder what they are doing differently than what I want.

There are no official docs, and I'm not sure if I'm understanding how this should be set up. Let's say I have two disks that are to be my shared volumes, I'm pretty sure I want to start of by: Creating zpool tank0 on these two volumes Creating a zfs volume for gluster fs in that tank...

I finally got it going. The procedure not pretty, but effective: Bork system trying to build zfs for 4.7 kernel, Reinstall from backup git clone pve-kernel Start compile, allow it to unpack tarball and patch source Ctrl+C Replace the .config with native 4.4.13-r2 config file from /boot Fix...

Just to be clear, there are two patches in question: There is the ZFS patch that comes with pve-kernel sources. There is a patch to intel-iommu.c which I need to apply for iommu to work on my motherboard. If I use kernel 4.7, I don't need the second patch, but I always need to add ZFS root...

The pve-kernel sources I checked out come with ubuntu-xenial kernel sources, and a ZFS patch for the same. When I try to manually build that kernel it fails with the error in OP. Short of being able to determine why this is, what are my options? I have to build a kernel manually with ZFS...

Pardon me if I'm misunderstanding you, but isn't the 4.4 ubuntu-lts kernel the same one that I check out from the proxmox repository (ubuntu-xenial)? I went ahead and checked it out out anyway as per this page: https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide make kernelversion also returns...

I'm experimenting with PCI passthru and multiseat on proxmox. The former works well, and impressively so. I can even pass two GPU to one VM, and have no problem. However, if I start a second VM and pass a GPU to it, then within minutes of starting anything 3D intensive on one, such as a game...

Bump for update of thread

UPDATE: This is solved. See a few posts down for how I did it. The purpose was to revert a patch applied to the intel-iommu driver, breaking it for many X58 boards, pending the official bugfix. I need to patch the pve-kernel due to a bug concerning my mb and iommu. I check out the...

The thing crash on me before I could test the module. Once again, all I got was a link to the debug kernel. The date matches the time of the crash.

I've made some progress. DEBUG_KERNEL was not set on my end. I copied my current kernel to / and called in vmlinuz, so as to match your config exactly. # service kdump-tools status ● kdump-tools.service - Kernel crash dump capture service Loaded: loaded...

I wanna correct something I said above for posterity: Aside from the hostpci: stuff, I also had to add "machine: q35" to vmid.conf file. The wiki is somewhat ambiguous as to what is and is not necessary in the example it gives for UEFI GPU passthrough. Due to the current bug whereby OVMF...

There doesn't seem to be any documentation for enabling crash dumps in debian, and what I've cobbled together does not seem to be working. # cat /etc/default/kexec # Defaults for kexec initscript # sourced by /etc/init.d/kexec and /etc/init.d/kexec-load # Load a kexec kernel (true/false)...