Closed Bug 1104023 Opened 11 years ago Closed 11 years ago

Replace Zeus SSC hosts with virtual appliance

Categories

(Infrastructure & Operations :: Virtualization, task)

Product:
Infrastructure & Operations
Component:
Virtualization
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gozer, Assigned: cknowles)

References

Details

(Whiteboard: [vm-delete:2][vm-create:2])

In bug 1101697, I requested 2 VMs for the Zeus SSC product we want to try and use. Unfortunately for me, the installable version of their product doesn't include a GUI, something we need... Instead, the other option is an OVA template that includes all their stuff. Could I just get these existing VMs nuked and re-created from that virtual appliance image? Apologies for the wasted effort, but it was far from clear from the documentation this would be the case. Also, the OVA template is behind a paywall, so let me know where you want me to put it so you can grab it easily. Thanks again!
I put this in IRC, but let's be consistent about things. on admin1, there's a /mnt/scratch, feel free to drop it there in the appropriate datacenter. Did you just want two VM's of the same names as the ones that are getting nuked? ssc1.ops.{scl3,phx1}.mozilla.com ?
I am uploading to: admin1.private.scl3.mozilla.com:/mnt/scratch/gozer/Riverbed_SSC_1.3_Host-Virtual-Appliance-x86_vmware.zip 4abacd3cdd0d2a3218aea84a2767949d97bfe4fb Riverbed_SSC_1.3_Host-Virtual-Appliance-x86_vmware.zip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlRzQiYACgkQyzKhB4jDpaUW+ACfUYTkOhwEjAqfyVJiFTTTrjgf eA4An3X4Xbl6wvWhgxbT9j4KGvo4fkYj =+iUv -----END PGP SIGNATURE-----
(In reply to Chris Knowles [:cknowles] from comment #1) > I put this in IRC, but let's be consistent about things. > > on admin1, there's a /mnt/scratch, feel free to drop it there in the > appropriate datacenter. > > Did you just want two VM's of the same names as the ones that are getting > nuked? Yes, running their software on RHEL is a bust, I need to use their silly appliances, so nuke away, keeping hostnames/IPs/etc > ssc1.ops.{scl3,phx1}.mozilla.com ? Yup, kill them with prejudice anytime you want. Once up, I'll take care of puppetizing the virtual appliances.
OVA template uploaded successfully.
Alright, have removed the old SSC's, will get to copying and working on the OVA deploy. Will update with any questions/concerns. I have set the ssc's to 1 day downtime in nagios.
Assignee: server-ops-virtualization → cknowles
Whiteboard: [vm-delete:2]
So, when I attempt to deploy - it's asking me to define three network/vlan mappings, a mgmt vlan (OPS, I'm guessing) a 'wan' vlan, and a 'lan' vlan. Guidance as to where I should put those?
(In reply to Chris Knowles [:cknowles] from comment #6) > So, when I attempt to deploy - it's asking me to define three network/vlan > mappings, a mgmt vlan (OPS, I'm guessing) a 'wan' vlan, and a 'lan' vlan. Oy, I didn't try the appliance myself, sorry for the incomplete instructions. AFAIK, should only be configured for the mgmt vlan (OPS) and the others shouldn't be necessary. According to the docs, anyways. I am going to spin up my own copy of the appliance to check how that works. > Guidance as to where I should put those? If at all possible, just configure the mgmt network and leave it to me to finish the rest.
(In reply to Chris Knowles [:cknowles] from comment #6) > So, when I attempt to deploy - it's asking me to define three network/vlan > mappings, a mgmt vlan (OPS, I'm guessing) a 'wan' vlan, and a 'lan' vlan. > > Guidance as to where I should put those? Or did I misunderstand, and is this inside vmware, when creating the VMs? It's asking for 3 interfaces? In that case, it's simple, just create one network interface for the VM, and stick it in the OPS vlan.
When you do an OVA deploy, it's all setup by the folks that made the OVA. You have to map the 3 cards to some vlan - based on your earlier comments, I mapped the NICs as follows: 1: mgmt: ops 2: WAN: private 3: LAN: private And then I made the interfaces 2 and 3 disabled on the VM, so they shouldn't try to come up. They should be ready to power on shortly. I'll either update that they're ready for you, or you'll hear an earth shattering kaboom.
(In reply to Chris Knowles [:cknowles] from comment #9) > When you do an OVA deploy, it's all setup by the folks that made the OVA. > > You have to map the 3 cards to some vlan - based on your earlier comments, I > mapped the NICs as follows: > > 1: mgmt: ops > 2: WAN: private > 3: LAN: private > > And then I made the interfaces 2 and 3 disabled on the VM, so they shouldn't > try to come up. Perfect, should be just fine! > They should be ready to power on shortly. I'll either update that they're > ready for you, or you'll hear an earth shattering kaboom. Allrighty!
Alright, I didn't hear an earth shattering kaboom, and I can ping the VMs, though I don't have creds to do any further checking. They're already in nagios (downtimed until tomorrow to give you some room to custom and work on these...) They've already got vmtools from their ubuntu installs - so that's good. Is there anything else that I can do to help?
What's the reason behind the multihoming here? Do you still need the ops interface for some L2 only communication?
Well, given that this is a new product, I'm unwilling to just hack out the interfaces that the vendor installed - however, as I stated earlier, the interfaces 2 and 3 are currently disabled at the virtual center layer, so it's not *really* multihomed. If :gozer says it's alright to remove those interfaces altogether, I certainly can, but didn't want to remove our ability to do anything needed. Alternatively, if you'd like, we can put those disconnected interfaces on the ops vlan, so that if they ever *did* get activated by accident, they'd be in teh same vlan as their management. Let me know how I can help.
(In reply to Michal Purzynski [:michal`] (use NEEDINFO) from comment #12) > What's the reason behind the multihoming here? Do you still need the ops > interface for some L2 only communication? No, that's only needed for the version of their product where the SSC controls/launches/manages virtual ZLBs. Not our use case here. The only thing this is going to be doing is ocasionally ssh into the ZLBs, and the ZLBs will talk to it from time to time over a REST API.
Gotta love Riverbed, wrong OVA template... I've just uploaded a new one (the last time, I promise) and it's in the same place: 345a8c3da9811cd844038d2b7756402c990c8ee7 Riverbed_SSC_1.3_Controller-Virtual-Appliance-x86_vmware.zip Should explain why the documentation didn't seem to match what was hapenning at initial boot-up. Just nuke away and re-create with this one. You can keep the other 2 interfaces disabled and in the OPS VLAN, as suggested in comment #13, that's a great idea. The initial setup wizard should start up on the console quickly, and it's safe to just follow defaults and not enter anything at all, like licenses and the like, I'll be able to do it myself once it's up and running.
<laughter> Alrighty then. I'll get the OVA copied where I need it, but will likely not have time to deploy until tomorrow morning...
(In reply to Chris Knowles [:cknowles] from comment #16) > <laughter> > Alrighty then. I'll get the OVA copied where I need it, but will likely not > have time to deploy until tomorrow morning... No worries, I realise it's been a lot of useless back-n-forth. Wish I could help instead of just being on the sidelines causing work. Tomorrow morning is more than fine, as long as I can get to it before EOD tomorrow, I'll be fine.
Alright, Those two VMs are up and running. No prompts occurred during bootup, just came straight to a prompt: "amnesiac login:" Let me know if you need anything else.
Whiteboard: [vm-delete:2] → [vm-delete:2][vm-create:2]
Just checking in, are you good to go here?
Yes, sorry, they were just perfect.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
See Also: → 1109189
You need to log in before you can comment on or make changes to this bug.