Search results

My clocks are in sync... when I observed them. This could be a good clue still. My 2 main nodes are bare-metal, but my 3rd node is a VM (bhyve). Maybe the host's network timesync is messing with the date periodically? Anyone can put some weight on this?

We have a 3 node setup. The lesser 3rd node, only used only as a replication target for backup puporses, still has the issue. We have since purchased the license subscription and are currently running Virtual Environment 6.1-8. Since the affected node can be rebooted, I have added this as a...

Browser doesn't seem to be the issue. I am still trying to fix this. It reoccurs for us every 10 days or so.

FYI, this never got implemented. However, the following not so obvious steps bit alleviate the original problem, which is the long down time while the transfer is occurring: establishing a "replication" task to the target node let this replication proceed at least once (this happens while the...

Figured out the Dell problem... If you enable the new feature flags on your pool (zpool upgrade), the old grub 2.02-pve4 will not see your pool anymore. error: [1] incorrect dnode type: 196 != 16 (thanks for this great error message GRUB!) Hence this topic creeping up again! Upgrading iDRAC...

Check if your iDRAC is at the latest version. From the klunky EFI system management module, there's an update component which looks to ftp.dell.com and auto-finds all updates to apply. Slow as hell, but works. The issue with the hang seems to be related to a virtual floppy disk (fd0) which grub...

We are starting to consider moving away from proxmox... sadly.

For reference, we should strive to converge all versionning to a true industry standard: https://semver.org

+1, really sad, we were upgrading Proxmox to get some of the performance improvements of 0.7.x, instead, things are slightly worst. How is this going un-noticed during testing? Could it have anything to do with compression=lz4 or having SSD cache disks?

I had already gone through this pain when 2.02-pve5 came out. Even posted here back then: https://forum.proxmox.com/threads/grub2-2-02-pve5-breaks-on-gpt-efi-disks-like-zfs-roots.30944 I had no choice but to reinstall 2.02-pve4 and then `apt-mark hold grub-pc=2.02-pve4`. Honestly, if the system...

Broke my system... for the second time on an update. Last time was the grub boot problem. Why would anyone want to update their grub on a stable system... I am booted and in the system already! This is only risk. So I pinned the grub-pc package to workaround it. Yes I falsely assumed an apt-get...

Here's my pool config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 sda2...

Hi, I posted to https://forum.proxmox.com/threads/call-for-testing-updated-grub2-packages.30361/#post-155422 about this. Thought I'd plant more seeds here about the issue. I think there's a problem with the update. I gathered that the pve5 update dropped patches for zfs in favour of upstream...

Different story for me. The update to 2.02-pve5 "broke" my system. HBA SAS adapter with zfs RAID1+0 setup on dell PowerEdge R510. I later found out that the system eventually boots after a about 40 minutes!!! (I could afford to let it sit at the bios post screen where it hangs for that long...

WARNING!! I AM NOT A PERL DEVELOPPER, THIS IS MY FIRST ATTEMPT AT HACKING PERL. So I made a crude implementation of what I would call "quick stop" (or suspend) pseudo live migration of LXC. Here's the patch ( I will also send on the mailing list): Index: /usr/share/perl5/PVE/LXC/Migrate.pm...

FYI, see https://forum.proxmox.com/threads/online-migration.27968/#post-146812

I'm running my lxc containers on zfs storage. Having some offline time is not such a big problem. The problem is how long the containers are down. Problem is the long part of the migration is the zfs snapshots transfer. In theory, it is feasable to: zfs snapshot the running container pre-send...

Also, don't forget to test your excludes. For example, another thing that didn't work for me was the '/dir/.+' notation, instead, I had to use '/dir1/*'

Just to follow up on this... the pve-manager git repo has just seen a series of commits related to this, it should then be fixed in an upcoming release. In the meantime, you can apply these changes manually to your instance in the VZDump.pm file if you are stuck. vzdump: don't double...

I've posted at pve-devel mailing list an hour or so ago... here's my current "patch" which seems to work well right now: --- VZDump.pm | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/VZDump.pm b/VZDump.pm index 54cea9c..0a3a2b3 100644 --- a/VZDump.pm +++...