The fix seems to be working, but there still are problems: If there is some vm, that has the port allocated (in the .vmx), then it seems we are getting ports unique, but if there is something listening on the ports, nova will try to use it: Bind the port on ESXi ESXi# for i in $(seq 9100 9105); do nc -d -l "$i" & done Boot the vm: ssh root.3.4 '. keystonerc_admin && nova boot --image cirros-0.3.1-x86_64-disk.vmdk --flavor m1.small foo Check the allocations: ~ # grep vnc /vmfs/volumes/datastore1/*/*.vmx /vmfs/volumes/datastore1/5333299c-bb91-4fd7-b33a-448f401fdad8/5333299c-bb91-4fd7-b33a-448f401fdad8.vmx:RemoteDisplay.vnc.enabled = "true" /vmfs/volumes/datastore1/5333299c-bb91-4fd7-b33a-448f401fdad8/5333299c-bb91-4fd7-b33a-448f401fdad8.vmx:RemoteDisplay.vnc.port = "9101" /vmfs/volumes/datastore1/afwe/afwe.vmx:RemoteDisplay.vnc.enabled = "true" /vmfs/volumes/datastore1/afwe/afwe.vmx:RemoteDisplay.vnc.port = "9100" Note the afwe is some shutdown machine that I have created there manually. The 5333299c-... is the nova booted VM. This means: * There is danger of collisions with the running daemons -- for example there is: tcp 127.0.0.1:5988 0.0.0.0:0 LISTEN 34780 newreno sfcb-HTTP-Daemo * There is a danger of collisions with clients running on ESXi, that are making connections from random ports. Also, be examining the patch, it seems like the port range is per vcenter, not per ESXi, this means that we are going to be able to run just a handful of machines, or the collision danger increases. I suggest to let the vCenter pick the random, available port, not nova, if it is possible. For this reason, I am going to either set this back to ASSIGNED, or clone and VERIFY.
I forgot to say that the VNC was, of course, not working, when nova picked the port which was used by something else. I have not seen any error in the compute log though. Steve, what do you think we should do? Should I update the BZ 1069430 about that ESXi should be picking the port?
(In reply to Jaroslav Henner from comment #2) > The fix seems to be working, but there still are problems: > > If there is some vm, that has the port allocated (in the .vmx), then it > seems we are getting ports unique, but if there is something listening on > the ports, nova will try to use it: > > Bind the port on ESXi > ESXi# for i in $(seq 9100 9105); do nc -d -l "$i" & done > > Boot the vm: > ssh root.3.4 '. keystonerc_admin && nova boot --image > cirros-0.3.1-x86_64-disk.vmdk --flavor m1.small foo > > Check the allocations: > ~ # grep vnc /vmfs/volumes/datastore1/*/*.vmx > /vmfs/volumes/datastore1/5333299c-bb91-4fd7-b33a-448f401fdad8/5333299c-bb91- > 4fd7-b33a-448f401fdad8.vmx:RemoteDisplay.vnc.enabled = "true" > /vmfs/volumes/datastore1/5333299c-bb91-4fd7-b33a-448f401fdad8/5333299c-bb91- > 4fd7-b33a-448f401fdad8.vmx:RemoteDisplay.vnc.port = "9101" > /vmfs/volumes/datastore1/afwe/afwe.vmx:RemoteDisplay.vnc.enabled = "true" > /vmfs/volumes/datastore1/afwe/afwe.vmx:RemoteDisplay.vnc.port = "9100" > > Note the afwe is some shutdown machine that I have created there manually. > The 5333299c-... is the nova booted VM. > > This means: > * There is danger of collisions with the running daemons -- for example > there is: > tcp 127.0.0.1:5988 0.0.0.0:0 LISTEN 34780 newreno > sfcb-HTTP-Daemo > * There is a danger of collisions with clients running on ESXi, that are > making connections from random ports. > > Also, be examining the patch, it seems like the port range is per vcenter, > not per ESXi, this means that we are going to be able to run just a handful > of machines, or the collision danger increases. > > I suggest to let the vCenter pick the random, available port, not nova, if > it is possible. For this reason, I am going to either set this back to > ASSIGNED, or clone and VERIFY. ESX doesn't support the automatic allocation of VNC port numbers: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1246
(In reply to Jaroslav Henner from comment #2) > The fix seems to be working, but there still are problems: > > If there is some vm, that has the port allocated (in the .vmx), then it > seems we are getting ports unique, but if there is something listening on > the ports, nova will try to use it: > > Bind the port on ESXi > ESXi# for i in $(seq 9100 9105); do nc -d -l "$i" & done I don't think this is worth worrying about, because: 1. Port usage on ESX is down to the administrator 2. There are config variables to define the range that Nova uses 3. The default Nova port range won't conflict with default ESX services i.e. It will work out of the box, and if the admin wants to do something out of the ordinary they have tunables to enable this.
(In reply to Matthew Booth from comment #5) > (In reply to Jaroslav Henner from comment #2) > > The fix seems to be working, but there still are problems: > > > > If there is some vm, that has the port allocated (in the .vmx), then it > > seems we are getting ports unique, but if there is something listening on > > the ports, nova will try to use it: > > > > Bind the port on ESXi > > ESXi# for i in $(seq 9100 9105); do nc -d -l "$i" & done > > I don't think this is worth worrying about, because: > > 1. Port usage on ESX is down to the administrator > 2. There are config variables to define the range that Nova uses > 3. The default Nova port range won't conflict with default ESX services I don't think the point 3) is true because I see those defaults in the nova.conf: # Options defined in nova.virt.vmwareapi.driver ... # VNC starting port (integer value) #vnc_port=5900 # Total number of VNC ports (integer value) #vnc_port_total=10000 That means we need ports 5900-15900 for the VMS. and as I wrote above, I have discovered this on the ESXi. I believe my ESXi is in pretty much default configuration. > tcp 127.0.0.1:5988 0.0.0.0:0 LISTEN 34780 newreno and this means that the 88th VM will not hace working VNC. > > i.e. It will work out of the box, and if the admin wants to do something out > of the ordinary they have tunables to enable this.
Sorry, I have found that VNC is binding zeros while the hostd-worker service is binding 127.0.0.1:5988. That means that 0.0.0.0:5988 is available, checked: ~ # nc -l 0.0.0.0 5988 & ~ # nc -l 0.0.0.0 5988 & ~ # nc: Address already in use ~ # kill-9 %
Needinfo: Matthew Booth re your comment in the Doc Text field: "mbooth: I don't understand what the above text means." If you look above the Doc Text field in this bug you will see the Doc Type field. It is a dropdown field where you need to choose the correct item, e.g. is this a bug fix, or an enhancement, or a rebase for bug fix etc. This determines how this bug's Doc Text is treated in the errata. Depending on the choice you make in the Doc Type field, the prompt text you see in the Doc Text field changes. For example if you choose Bug Fix, then the Doc text field asks you to fill in Cause, Consequence, Fix, Result. If you choose Rebase ..., you also need to fill in what version you rebased to, and so on. Please choose the correct type in Doc Type, and then fill in the Doc Text accordingly. NOTE: copy your existing text from the Doc Text field first, lest you lose it when you select a different Doc Type. Hope this makes it clearer. Thanks
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0578.html