New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
SolusVM Update - v1.16.01
Maximum_VPS
Member
http://docs.solusvm.com/release_versions_stable#section11601
Fixes/Changes/Features:
- Added ability for admin/client to add/remove IPv6 addresses from assigned IPv6 subnets.
- Added reverse dns options for IPv6 subnets.
- An IPv6 address from the first subnet will be assigned to a vps automatically when a virtual server is created with an IPv6 subnet.
- Added option to check IPv6 subnets against the singular ipv6 table for matches. Subnets matched will be marked as reserved.
- IPv6 subnets are returned in the admin API vserver-infoall call. http://docs.solusvm.com/v2/Default.htm#Developer/Admin-Api/Virtual-Server-Functions/Information-All.htm
- IPv6 subnet prefixes are now passed to ebtables.
- Fixed issue where KVM virtual servers would sporadically show as offline in the client area.
Comments
That was the most exciting part for me, @soluslabs is this just for the new IPv6 implementation or have you considered the legacy IPv6 system in this?
Oh good clients can bind individual ips in the subnets now!
@soluslabs, suggestion to make it a big button like the re-install button. It's a tad un-clear where you go to add IPs to the existing subnet.
Just checked, ebtables still kills IPv6.
Seriously, it's nog that hard... /failderps
Previously the /64 or whatever you use was not passed to the ebtables system. It is now.
The ebtables system will be removed when the new arp system is in place. I don't know off hand what the status is on that though.
You can use the hook for v6? It's a one off edit.
You mean because it's under the network tab on the client side?
Sorry just for clarity, you are saying that the /64 is passed the ebtables but in order for it to actually work the one off edit is required per slave correct?
I ask as when I brought this issue up 2 - 3 years ago Jason or Phill sent me essentially the same one off edit back then and it made no difference.
Also what progress has been made on automating the transition from the legacy to the new ipv6 system, I assume/hope it if fair to say you are not expecting your customers to manually reassign everything?
Thanks.
Ant.
Yes that's what im saying. That method does work. I've just tested on a Ramnode server.
Any IP i add from the subnet pings fine.
You may have been testing it on a CentOS 5 host with no IPv6 support in ebtables?
You requested an option to check subnets against singular ip's which was added. I don't know what else you want? You want to add a subnet to each vps that has a singular ip assigned to it? What then. You want a grace period for the old ip(s) then remove them at a later date?
Yes based on the new IPv6 subnet system, how about for the legacy assigned IPv6?
ip6 support has been in place since 2.6.x , I brought it up again for CentOS 6 when I switched anyway and never got any answer, the ticket sat in management review for about a year.
Yes that was the first part of my question in post: http://lowendtalk.com/discussion/comment/683751/#Comment_683751
Here is the rest for convenience:
--
Few questions on the ipv6 subnets then which no doubt a few people are thinking.
Will it specifically avoid creating subnets that already contain addresses generated at random from the previous system?
Is there now or will there be something put in place to properly convert from one method to the other, right now it seems the steps I would have to take are?
1) Select a VPS
2) Click IP's button
3) Click the x next to each IPv6 address assigned
4) Remove the IP's from whmcs after finding the corresponding account.
5) Assign new IPv6 range
6) Update WHMCS with new IPv6 range.
7) Email customer with new IPv6 info.
Is that about the top and bottom of it?
--
@soluslabs was the issue with DHCP custom header file not being used at all resolved? This still plagues me.
Yes the legacy IPv6 will pass through that hook aswell.
You add your subnets as normal. Even if you have singular ip's in the same range. After the subnets are added you select ALL the subnets generated and click the "Check for Duplicates in IPv6 Table" it will then reserve any subnets that clash with the singular ip's. The reserved subnets can then be either removed or set back to free when you remove the old ip's.
That's basically the steps. You can also assign a subnet to a vm directly from the subnet list.
I suggest you assign a subnet to each vm and give the client a time limit to setup the new subnet before removing the old. They can then assign what ip's they want from the new subnet.
Do you have a ticket id? if not check the custom header file is readable by solusvm:solusvm
That does not really cover it though, you talk about removing the old like it is a walk in the park, I currently have 28124 IPv6 individually assigned through your legacy system for IPv6
Per VPS with lets say an avg of 5x IPv6, that is around 30 seconds to remove 5 x IPv6 addresses, then 30 seconds to assign a range, then another 30 seconds to update WHMCS and send the user the details of their new range.
That is 506232 seconds to complete this task or 141 hours or 5.8 solid none stop 24x7 day to complete if I did absolutely nothing but that.
I cant be the only one thinking that is unreasonable.... am I?
I'm skimming this so forgive me if I missed it, but what is the main reason you want to remove those individual IPs?
Well, a few reasons.
1) Because I don't expect solusvm to be developing any future compatibility in to the legacy system and something will no doubt crop up in the future.
2) Because why would I want half a job and a mish mash of systems in a live environment?
3) Because based on experience I fully expect ticket after ticket asking me to remove the old IP's when a new subnet is assigned.
4) It keeps things clean and orderly.
edit, even if I don't remove them and simply assign a new ipv6 range to every VPS, update WHMCS and send details to clients that is still 3.9 days of work 24x7 if doing nothing but that and I still do not think that is reasonable.
.........
Converting would obviously be done via a script. There's no other way around that. There's also more than one step here. You would need to give your clients time to start using the new subnet before you removed the old ip's, i'm not sure they would take kindly to a straight switch but i may be wrong.
1) Assigning a subnet to a VM is only an SQL query so that's not an issue. The issue is knowing which VM's need a subnet and which ones don't.
2) The client would then assign there own IP's so that's also not an issue.
3) Removing the old ip's would ideally need to be done a week or two after the deployment of a subnet and that can't be done with just an SQL query. The old ip's would need to be removed from the VM in the case of OpenVZ and a reboot in the case of Xen/KVM.
I'd prefer you to suggest how you think this should be done as apposed to back and forth like this.
Look, this is going to sound like the kind of dick statement that made you guys publicly brand me "the idiot" to begin with.... but really, I pay you for this, that is something you should have WAY more experience than me in and really should have thought about in advance.
You don't just change a fundamental system then expect your customers to pick up the pieces, so my suggestion is, lock yourself in a room, study the code that only you know best and come up with a solution.
However as you asked, here is how I would do it.
Script an update that adds a button to every customers control panel that has legacy IPv6 called "convert IPv6 legacy to range" give a warning when they press the button that states they will lose current addresses within 24 hours (cron) when they click confirm it assigns the new range, callback to WHMCS and update the info.
Done.
Anyone else have to reboot OpenVZ containers after adding/removing an IPv6 from the client end?
Ermm.. Nobody is asking you to use the subnet system. You can use the older system for as long as you like. It's not a change we are forcing you to make and no date has been set to remove it.
This was a question to you out of genuine interest in how you thought it should be done. I would have never of thought of giving a client the option to convert to a subnet from an old assignment directly from the client area. This just shows that a hosters view is totally different to a developers view.
Honestly Anthony there's no need for us to keep sniping at each other especially on public forums. Life is way to short for that
Way way to short!
That will most likely be vzctl -ipadd killing the networking. I see you have a ticket in so i'll reply to that.
@soluslabs any update on backups?
http://blog.soluslabs.com/2014/04/13/what-to-expect-from-solusvm-v1-16/
Fair enough, I will just wait and see what next weeks update brings then, now you have introduced the change it will become an expected facility soon enough though so market demand and change does dictate the switch is required.
Well..... We made a decision last month (after we put a new team together) that we would push out only the IPv6 subnets in v1.16, Next will be the new Auto Backups (was Auto FTP Backups but now supports SFTP, SCP etc...) in v1.17 then in v1.18 would come the client side backups.
Most of the above is already written and working. The Auto Backups just need the restore functions tweaking and that's ready to rumble, The client backups are a lot more complex than that!
I'd second the addition of converting on the client side. That'd be really nice. Even if it removed the old IPv6 right then and there with a warning. Clients would at least have the choice!
Sounds like a plan. My idea is to add an option to mark a legacy ipv6 block as "legacy". When the block is marked as legacy the client area will check to see if a new Ipv6 subnet block exists for the node the client is on. If so it will offer the client an option to switch over.
Sounds good to me.
Please do not remove the capability of adding individual IPv6 addresses as not all hosts offer /56 or more with a dedicated server. Would really appreciate if the current system also stays.
If that is what is needed for you to correct a bug in your software, sure. I played along.
ARQ-293236
Are you paying support per ticket because I wouldn't pay that guy for his first reply lol.
I assume the option to split a /64 in to /112's exists ?