Search results

I filed the report under pve-storage https://bugzilla.proxmox.com/show_bug.cgi?id=994 Thanks

I would post a bug report to bugzilla.proxmox.com about the /var/log/dmesg issue ... it may not be a bug but you'd find out fairly quick and they'd likely make comments about whether or not it has to do with SystemD and updated methods of logging or not

Looks perfect .... so at this point, you've upgraded to 4.2 and changed this file to re-order your NIC names? Nothing else changed? I've noticed myself when re-ordering the NIC names using the udev method that there are delays in bringing up the interfaces during boot but once the system was up...

Can you post the 70-persistent-net.rules file? You may find this all to be much cleaner if you use the SystemD method for changing NIC names as I mentioned earlier. I'm sure there is a reason the 70-persistent-net.rules file is gone in Proxmox 4.2 with a fresh install. The SystemD method is...

vmbr0 - has both IPv4 and IPv6 addresses vmbr1 - has no IP and has eth1 as slave vmbr2 - has no IP and has eth2 as slave vmbr3 - has no IP and has eth3 as slave eth4 - autostart - IPv6 address on another /64 network different than the public which will be used for Ceph communication (no IPv4...

What component should it be filed under? pve-storage? or something different?

Did you modify your 70-persistent-net.rules file? If you modify that file it needs to stay in the same format that it was originally otherwise the OS has a hard time parsing the file and networking can be slow to come up or not come up at all.

If you are simply trying to re-order the names of your Network Interface Cards, you can use SystemD directly to do this by using .link files It's under /etc/systemd/network folder you'd create these These files would be named something like 10-eth0.link and would contain something like the...

Ok, at this point, I may need to wipe the cluster out and move forward with Ceph testing on IPv4 but WILL come back to this as the problems with IPv6 need to get resolved. Problems with creating monitors and problems with Unparsable URL (599) are just the beginning I think. Thanks in advance

FYI, as of the 16th of May and Proxmox 4.2-4, this problem still exists. I have a cluster that's fully IPv6 and getting the Unparsable URL (599) error for large parts of the Web Interface. I'm not prepared to dump IPv6 ... can a Proxmox member please advise as to how this can be fixed or at...

I rebooted the node after attempting to create the first monitor When trying to start the monitor now on that node this is what I get Task viewer: SRV mon.0 - Start Output Status Stop === mon.0 === Starting Ceph mon.0 on PMX-72-CN1... Running as unit ceph-mon.0.1463160483.061314256.service...

This cluster is working over IPv6 and the Ceph install is intended to be entirely IPv6 Deploying ceph with pveceph install -version hammer works just fine on all nodes When deploying the first monitor, using pveceph createmon It reaches the the end with "Starting ceph-create-keys on "node...

multicast had been reliable, yes ... we ARE working on changing out from 1Gb switching to 10Gb switching and retrofitting the servers' NICs so that they communicate over 10Gb which is helping in many ways I'm certainly good with considering it a rare hiccup from corosync and leaving it for now...

Just to confirm Migration is now working just fine Thanks again for prodding me the right direction and again, if you think it'd be good to test a bit more just let me know, if not, we'll call this one licked

No, to be frank, I had already restarted the corosync service on the "unhealthy" nodes before trying your suggestion of the adding the empty file to /etc/pve Your questions were enough to prod my thought process so it was this dialog back and forth that got the ball rolling and made me think to...

To answer your first question, yes, test.tmp appears on all nodes I restarted the corosync service on the "unhealthy" nodes and now their .member files show all nodes and the correct version number I'll have to test the ability to migrate to the new node now I guess to see if restarting...

It's not that they are unhealthy or even act unhealthy ... the 3 that can't migrate a VM to the PMX-73-V simply give the error, no such node PMX-72-I ("healthy node") root@PMX-72-I:~# systemctl status corosync ● corosync.service - Corosync Cluster Engine Loaded: loaded...

No, there were no errors joining the node and it was working fine in the beginning. We were able to move Virtual machines from a node that now can't. The newest node is PMX-73-V. Here is the corosync.conf root@PMX-72-I:~# cat /etc/pve/corosync.conf logging { debug: off to_syslog: yes }...

We have a cluster of 8 nodes. One was JUST recently added. When trying to migrate a VM from a particular node to the new node it said "no such cluster node "node name"" After looking around, the /etc/pve/.members file doesn't match on all 8 nodes. It's the same on 5 nodes but 3 nodes have an...

Also, in case anyone in the know can help ... this issue, for me at least, started after upgrading pve-manager a couple of days ago from the pve-no-subscription repo ... in case this helps to track down a bug to keep it out of the Enterprise repo