Search results

apt remove --purge firmware-ralink firmware-brcm80211 firmware-realtek

Great, thanks.

Hi, same question, but for Proxmox VE (by example a shutdown task runnning forever because of qemu-agent dead inside guest) ?

Well, actually, not here: yes it works, the thinpool is activated at last... But Proxmox started before by systemd already tried to start the VMs, already failed, so at the end the thinpool is activated but the guest VMs aren't started. Is it expected to have systemd to start Proxmox before udev...

Very funny, pve5to6 declares: FAIL: Unsupported SSH Cipher configured for root in /root/.ssh/config: 3des With a cat /root/.ssh/config: Ciphers blowfish-cbc,aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc The fun thing is that this file was written by PVE5 itself...

In fact this is a debian stuff, and most probably not Promox related... I guess it compares the initial config recorded in debconf with the current media scheme. You may have a look at debconf-show grub-pc before and after the upgrade or dist-upgrade, to check what it changed in its record...

Proxmox guys have written everywhere to never use apt upgrade with proxmox, but always use apt dist-upgrade. But I do think they should append this information to the /etc/motd file at install.

It is not enough to activate the discard option in the host for this VM. You also have to mount your filesystem (within the guest) with the discard option if you want it to issue discard commands to the storage device. If you don't, it won't do anything. Or, you can use fstrim from time to time...

Excellent advice ; but as soon as you are in LACP you can distribute whatever you want and notably in layer3+4 (the other equipment will just accept the traffic, there's no limitation on this).

Updated yesterday (while upgrading from 4x1G to 2x10G LACP LAG) with 4.15.18-1. Running so far ; you can have a look at the logs below... [ 2.022749] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 5.1.0-k [ 2.022750] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [...

For encrypted traffic? If so, it could help to expose AES CPU Flag to the VM. So, try to set the VM CPU type to "host", shutdown the VM, then start it again.

The Intel microcode update has been withdrawn because of bugs, so basically nobody can be reliably protected against Spectre today. In the meanwhile, Linus explained how its use was crappy, and Google is developing retpoline to mitigate Spectre instead of relying to new x86 instructions. So...

Works with Debian9 image, doesn't work with Proxmox image, blame Proxmox installer.

Fixes CVE-2017-5754 (variant #3/Meltdown). Fixes CVE-2017-5753 (variant #1/Spectre) ? I guess there will be a next-to-come fix for CVE-2017-5715 (variant #2/Spectre), associating microcode update and IBRS kernel patch, correct ?

Well, I don't see what it would secure...

I don't think so, as you probably want to have pcid CPU flag exposed to your guests in order to mitigate the performance loss coming from the Kernel/User page tables isolation feature once your guest kernels are updated.

However you can configure HBA mode within the controller.

There's nothing wrong on the Cisco side, the issue is on the Linux side: you configure mode X and it chooses to use mode Y. Why? That's the question :P But I'm not sure it's a proxmox issue ; it can well be a more generic debian issue, maybe a race in the networkwing scripts...

I've quickly abandoned any hope to see the ISO Proxmox image able to boot my servers, I now always use a debian 9 ISO/USB image then follow the process https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Stretch However, this is an issue that should be addressed.

Yes, your problem is solved ; why the config wasn't allowed? Good question, as "it works here"... root@hv-co-01-pareq6:~# grep mode /etc/network/interfaces bond_mode 802.3ad root@hv-co-01-pareq6:~# cat /sys/class/net/bond0/bonding/mode 802.3ad 4 root@hv-co-01-pareq6:~# cat /etc/debian_version...