ProxmoxVE 4.1 Cluster - Connection error 599 Unparsable URL

[rotanid]

Hello,

we set up a new cluster with ProxmoxVE 4.1 (pve-no-subscription), 2 nodes, no HA.

one can see the VMs of the other cluster node and their disk/memory/cpu/uptime.

but when we click on on of these VMs on the other node (not the one where the browser points to) then an error appears above the "status" element saying "Unparsable URL (599)" and in the notes area it says "Error Connection error 599: Unparsable URL"

has anyone else experienced something like this?

 

[CTCcloud]

Yes, I'm experiencing the same thing for one of our nodes. If I go to the GUI of that node there's no problem but when accessing the cluster GUI from another node that's when I see that error exactly as you noted.

I'd love to hear of an answer from someone in the know as well.

Thanks in advance to anyone that may have an idea.

 

[CTCcloud]

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

 

[speedlnx]

same issue: pve-manager/4.1-15/8cd55b52 (running kernel: 4.2.8-1-pve)

 

[coppercore]

I can also confirm this is happening to me with a freshly installed and updated proxmox ve 4.1 joined as a second node.

Seems to be happening on both machines.

 

[coppercore]

Version information for both hosts:

proxmox-ve: 4.1-39 (running kernel: 4.2.8-1-pve)
pve-manager: 4.1-15 (running version: 4.1-15/8cd55b52)
pve-kernel-4.2.6-1-pve: 4.2.6-36
pve-kernel-4.2.8-1-pve: 4.2.8-39
lvm2: 2.02.116-pve2
corosync-pve: 2.3.5-2
libqb0: 1.0-1
pve-cluster: 4.0-33
qemu-server: 4.0-62
pve-firmware: 1.1-7
libpve-common-perl: 4.0-49
libpve-access-control: 4.0-11
libpve-storage-perl: 4.0-42
pve-libspice-server1: 0.12.5-2
vncterm: 1.2-1
pve-qemu-kvm: 2.5-9
pve-container: 1.0-46
pve-firewall: 2.0-18
pve-ha-manager: 1.0-24
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u1
lxc-pve: 1.1.5-7
lxcfs: 2.0.0-pve1
cgmanager: 0.39-pve1
criu: 1.6.0-1
zfsutils: 0.6.5-pve7~jessie

 

[stuntshell]

I´m running into the same issue, freshly installed cluster with 04 servers, I can access if I go straight to the IP, but not via cluster. PVE Manager seems to be the problem.

Thanks,

 

[coppercore]

Any word on this? This isn't necessarily a major issue but it is rather annoying to have to have a browser tab open for each physical host.

 

[speedlnx]

Ok, problem solved.

I removed every ipv6 reference on /etc/hosts of my clusters nodes.

The key was to look at the content of /etc/pve/.members where i saw that the node I can't reach via the web interface appear with his ipv6 address and not with the ipv4 one. So i delete his ipv6 address and name in his /etc/hosts files, restarted the cluster on every node and everything start works again as expected.

 

[coppercore]

Ok, problem solved.

I removed every ipv6 reference on /etc/hosts of my clusters nodes.

The key was to look at the content of /etc/pve/.members where i saw that the node I can't reach via the web interface appear with his ipv6 address and not with the ipv4 one. So i delete his ipv6 address and name in his /etc/hosts files, restarted the cluster on every node and everything start works again as expected.

This did the trick! Thank you so much.

But this obviously is a bug that needs to be looked at. I'm 99% sure that somewhere in the web interface code that all that needs to be added are brackets [] around any and all ipv6 addresses

Eg
https://2001:470:abcd:ef::1/ becomes https://[2001:470:abcd:ef::1] when passed to the web browser

All web browsers are not very smart and resolve IPv6 addresses as hostnames until you put [] around the address. This is quite annoying.

Commenting out IPv6 addresses in hosts works for now but still is a bit annoying.

 

[stuntshell]

OK, are you using IPv6 on your networks?
In my case it makes sense since I´m not, but I´m just making sure that this is the reason, on V3 the same sympton would be a quorum issue.
I rebooted the entire cluster and went one by one to each node and restarted the pveproxy. Before that I had green icons but had the 595 unparsable error.

Thanks,

 

[CTCcloud]

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 least provide a work around until patched?

Thanks in advance

 

[dcsapak]

hi,

could you post your network configuration, so that i can try to reproduce this

 

[CTCcloud]

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 address)
eth5 - autostart - IPv6 address on same network as eth4, also for Ceph communication (no IPv4 address)

/etc/hosts file has public IPv6 address mapped to hostname + domain, hostname, and pvelocalhost - no IPv4 info

Tell me if I'm missing anything you need to replicate this for your testing

 

[dcsapak]

after debugging, we now know that the problem is in a library from debian,
this is a bug which was already reported to debian, but the fixed package is only in unstable and not in jessie

we will examine our options (possibly we will offer a newer version of the package via our repositories)

 

[CTCcloud]

So, it's IPv6 related within that particular Debian library? Just to be able to understand it ...

Thanks Dominik

As always, excellent work by the Proxmox staff and developers

 

[dcsapak]

yes
it is the library libanyevent-http-perl which exists in jessie in version 2.21
and version 2.22 contains the relevant bugfix (to date only in unstable)

 

[CTCcloud]

Ok ... thanks again for clarifying ... very much appreciated

I looked it up and it seems it's not just in "unstable" but also "testing" a.k.a "Stretch" ... hopefully it won't be too far off and perhaps because it's in Stretch repos it'd be easier for you guys to include? Just thinking out loud ...

https://packages.debian.org/search?keywords=libanyevent-http-perl

 

[CTCcloud]

For anyone that is tracking this as we are, please note this URL here

http://osdir.com/ml/general/2015-05/msg26656.html

This shows that Debian has known about this for a year at this point and although it's in unstable and testing, unfortunately, it's still not in stable (Jessie) so apparently would need to be backported for sure at this point for Proxmox to be able to have IPv6 full support.

Regards

 

[Japje]

I'm running into the same issue, has there been any news on when the package will be updated? Or perhaps someone has already found a work-around (without giving up v6 connectivity)