Stallion 2 - pictures and daily updates :)
- Thread starter Francisco
- Start date
That already happens and is displayed on the ipaddresses page 
http://199.19.227.70/vserver/1/ipaddresses
I think I got the inbound/outbound in reverse though <_<
Woops >_>
Francisco
http://199.19.227.70/vserver/1/ipaddresses
I think I got the inbound/outbound in reverse though <_<
Woops >_>
Francisco
acd
New Member
If you start tracking bandwidth usage by account, that's going to start looking really weird and make accounting a bit odd. There was some weirdness on one of my VMs at LV last month that I wouldn't have noticed excepting that it was on a nearly unused kvm. Tracking only aggregate account bandwidth would have hidden that from me. Second, anyone who is managing VMs for other users most likely doesn't want to be co-opted into a single, per-account pool, running the risk that a single user could result in a freeze of every VM across their account. Granted, this scenario would require bad/no traffic accounting configuration on their part or a single-VM exploit, but it's possible (and as probable as an insecure Wordpress plugin) and it's something which would worry me in that position.
I'm not in a position to say for sure, but I'm pretty confident your traffic accounting could be modified with relative ease to support floating IPs/moving them from instance-to-instance at the same site, though you may want a dedicated router for this kind of IP to keep the main one from getting an aneurysm *cough*. The easiest way to do this that comes to mind is NAT + track bw by an internal IP; not the CG-bind-everyone-to-one-ip NAT, but the intelligent loadbalancer/failover kind of NAT.
Aldryic will probably curse me for suggesting this, but if you did want to move to pooled bandwidth, may I suggest instead that you initially provision one pool per VM, and thereafter allow free merging and splitting of the pool; not necessarily by quantity, but by VM (this limits the amount of tomfoolery going on). Let me illustrate what I mean in narrative:
I'm not in a position to say for sure, but I'm pretty confident your traffic accounting could be modified with relative ease to support floating IPs/moving them from instance-to-instance at the same site, though you may want a dedicated router for this kind of IP to keep the main one from getting an aneurysm *cough*. The easiest way to do this that comes to mind is NAT + track bw by an internal IP; not the CG-bind-everyone-to-one-ip NAT, but the intelligent loadbalancer/failover kind of NAT.
Aldryic will probably curse me for suggesting this, but if you did want to move to pooled bandwidth, may I suggest instead that you initially provision one pool per VM, and thereafter allow free merging and splitting of the pool; not necessarily by quantity, but by VM (this limits the amount of tomfoolery going on). Let me illustrate what I mean in narrative:
If that is unclear, it's because I've had too much caffeine for 3:30am.Story Time With TW said:
I think pooled bandwidth is just too touchy of a subject to work on right now.
We have a grocery list of features to be completed way before merged bandwidth To be honest, the merging is entirely on us just trying to give clients more options. It isn't a requested feature nor something that 'has' to be there.
I think the only feature some users would really like is being able to buy one-off bandwidth addons for a VM so they don't 'have' to buy a monthly addon if they only get heavy once in a blue moon.
Who knows. We have a ton of other things to get done before we start dreaming in the clouds.
Francisco
We have a grocery list of features to be completed way before merged bandwidth
To be honest, the merging is entirely on us just trying to give clients more options. It isn't a requested feature nor something that 'has' to be there.I think the only feature some users would really like is being able to buy one-off bandwidth addons for a VM so they don't 'have' to buy a monthly addon if they only get heavy once in a blue moon.
Who knows. We have a ton of other things to get done before we start dreaming in the clouds.
Francisco
I'm not going to just hold a hat draw for who we'd license to. The licensing would include the source and given how quickly some brands are to sell, I wouldn't want my hard work suddenly getting included in the sale of any brand.
Francisco
Sir, just so you know, I am addicted to ponies. I love unicorn, I eat corn for breakfast and my bed looks like a stallion.
Bahahahaha.
On another note, Aldryic has forwarded me the WHMCS module so i'll be integrating that on Monday/Tuesday. It shouldn't take me more than a few hours.
Francisco
I will take my pants off and willing to share my bed with you.
Over my dead body!
Last edited by a moderator:
Aldryic C'boas
The Pony
Why do I always get stuck with the camera <_<
Hi Everyone,
Been a while since I've updated this but here goes.
Our WHMCS module & API is almost 90 - 95% complete with only a few last hooks needed. We fully expect to have 10 - 15 VM's available this weekend though WHMCS that will have a coupon to make them free. The VM's will provision to stallion 2 where you'll be expected to give things a full run through.
The node side will be running 2.6.32 and I'll import all of our current media into the system.
No promises but I'll see about letting people that actually help test (and find bugs) can keep their VM's for free (for at least a year or something).
Francisco
Been a while since I've updated this but here goes.
Our WHMCS module & API is almost 90 - 95% complete with only a few last hooks needed. We fully expect to have 10 - 15 VM's available this weekend though WHMCS that will have a coupon to make them free. The VM's will provision to stallion 2 where you'll be expected to give things a full run through.
The node side will be running 2.6.32 and I'll import all of our current media into the system.
No promises but I'll see about letting people that actually help test (and find bugs) can keep their VM's for free (for at least a year or something).
Francisco
