• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

VM Workstation --> ESXI

T

ToddW2

2[H]4U
Joined
Nov 8, 2004
Messages
4,017
How many here develop their VMs on their windows desktop in WOrkstation to get it configured how you want, and then roll it out to your server?

I was reading up and this sounds really useful.

Just curious if it's a process or it's actually "that easy" ;)
 
Easy... but there's "easier" options out there.
 
It's easy, but deploying from template -> building in place is easier :p
 
Thanks guys.

I have WorkStation installed, so why not work on it locally and move it once I get it configured, and running how I want?
 
I do it because sometimes I am not at work or at the site the vm will be rolled out at. While it is not that often I do use it from time to time. Also works well if I want to build a learning vm for a co-worker and hand it off to them as an ovf file.
 
peanuthead said:
I do it because sometimes I am not at work or at the site the vm will be rolled out at. While it is not that often I do use it from time to time. Also works well if I want to build a learning vm for a co-worker and hand it off to them as an ovf file.
Click to expand...

This is true for me too, and a good point to bring up. Thanks.
 
ToddW2 said:
Thanks guys.

I have WorkStation installed, so why not work on it locally and move it once I get it configured, and running how I want?
Click to expand...

because a production VM is normally based on a standardized template, not a fresh build?
 
Sometimes for certain clients they are virtualized yet, so templates are built. Or in most cases they are only virtualizing one or two servers. It is purely an as needed basis. Either way they is a standard checklist followed.
 
lopoetve said:
because a production VM is normally based on a standardized template, not a fresh build?
Click to expand...

Maybe you missed the FIRST post where I stated "develop their VMs".

I'm not talking about launching VMs from Workstation to ESXI that are "ready to go" production ready... I'm talking about DEVELOPING the VM in Workstation to get it how I want, and THEN moving it to ESXI. Then, of course I could just build from templates/backups/images I have already.

I have various clients, and I like to tinker and tune things for optimal performance... I don't simply have 1 default config for all clients, and I'm also new to hosting my own ESXI stuff so I want to be clear on what I'm doing and not doing to find out if it's optimal. I'm not new to using VMs for clients in general, just new to the ground-up process.
 
ToddW2 said:
Maybe you missed the FIRST post where I stated "develop their VMs".

I'm not talking about launching VMs from Workstation to ESXI that are "ready to go" production ready... I'm talking about DEVELOPING the VM in Workstation to get it how I want, and THEN moving it to ESXI. Then, of course I could just build from templates/backups/images I have already.

I have various clients, and I like to tinker and tune things for optimal performance... I don't simply have 1 default config for all clients, and I'm also new to hosting my own ESXI stuff so I want to be clear on what I'm doing and not doing to find out if it's optimal. I'm not new to using VMs for clients in general, just new to the ground-up process.
Click to expand...

Because no one really does that, at least not in any kind of enterprise or medium+ business environment? :) Stop thinking about one offs and client-specific configurations, and build a deployment methodology that you have architected and maintain it.

Developing the VM is installing a base OS, needed corp packages (AV/monitoring packages for windows, nagios/etc for linux), patching it a bit, and then templating it. Everything from there is scripted on deploy for the application; Either you use something like vCAC/AppD with it's own software design system, or puppet/chef/vagrant, or docker/openstack/warden/etc. There's no hands-on development except for the architecting of those scripts/deployment methods, and you do those in the same environment that you're deploying to or your methodology is fundamentally flawed.

That way everything is completely standardized - architect once, deploy many, build everything off of the same building blocks so that you know what your baseline is. I haven't used workstation to author a building block VM or a workload-specific VM in probably 4-5 years, it's simply far easier to whack together the building block natively on ESX and then deploy from there, especially since that way i know the entire deployment process was built/tested/run where it's going to live, and never mind that the performance of ESX with an appropriate SAN is faster than anything I could get locally, and doesn't suck down any resources from my workstation.

Get familiar with those tools, and you'll find that your life has suddenly become MUCH more rich, and you can do a ~lot~ more in far less time that way (especially since you can repeat it totally hands off!)
 
lopoetve said:
Because no one really does that, at least not in any kind of enterprise or medium+ business environment? :) Stop thinking about one offs and client-specific configurations, and build a deployment methodology that you have architected and maintain it.
Click to expand...

It amazes me how many people can't see beyond their own usage and their own experiences. Just because something isn't standard or normal to you doesn't mean it's not being done in the business world SOMEWHERE. I love to do things that others aren't doing it's where the real money is made. I'm not an employee, I don't do the same shit over and over for a company. I solve unique problems, and optimize systems to perform at there best.... so yes I'm constantly tweaking, and changing packages/installs regularly based on client/performance/project/whatever, and want to test/dev locally.

What you just said NOT to do, is exactly WHAT I do. I solve CLIENT SPECIFIC problems, I fix things for them SPECIFICALLY. I don't have GENERIC SHIT sitting on the shelf to stuff at them. But I sure do have copies of their VMs on a scheduler, as well as other important stuff. Was that example harsh? Sure, but so was you TELLING ME how to do it because that's how it's done, I don't mind the advice but don't go overboard with the rules ;) lol.

We obviously use VMs for different purposes, and very little of what I do is repetitive VMs other than the ones for specific tasks, which is what you are getting at and I get that 100%. But that's not the point of this thread, and NOT the question I asked.

Like I said, I've been using VMs since they became a "thing" but only recently have I started playing around with local hosts and various hypervisors from the ground up to expand my knowledge and better expand my business.

And by "tweaking and configuring" VMs... I mean exactly that. Most clients don't use the same EVERYTHING as other clients but a baseline template is used... but from there I tweak, and I'd rather do it local/travel/whatever than rely on internet connection to my dev-host at home.

I can see where you're coming from with Workstation and developing on the 'actual' machine to be sure/safe, but your other problems... you're just projecting those problems onto myself and others, we may have better workstations. I know I built mine specifically for testing VMs and development. I appreciate the info you shared and your opinions but could do without the "this way" talk, that's exactly how people get in holes, and it's not exactly good for business ;)
 
I'm not disagreeing with your concepts, I'm disagreeing with your methods. I worked at VMware for a ~very~ long time as one of their lead architects - I'm talking about the recommended (and implemented) method that the most successful customers and businesses have. Feel free to do it your way, of course, but that's certainly not what I'd recommend for most folks, nor is it how the industry is heading right now.

I'd argue that the VM is completely unimportant; it's nothing more than an API to consume resources. What matters is tuning the application and the workload for the customer's requirements, and the only place to do that is on ~their~ systems, since that's where it'll run in the end anyway. Workstation's hypervisor engine is significantly different from what is in the core of ESX - what runs well on WS will not necessarily run well on ESX, and vice-versa - they have very different goals and purposes these days. I totally agree that you need to be adjusting things to fit the requirements of a customer, but that starts with a standardized building block with a given set of criteria, and then is customized from there, on the system in question so you can size/tune appropriately to the actual hardware that is providing the resources you are consuming.
 
ToddW2 said:
It amazes me how many people can't see beyond their own usage and their own experiences. Just because something isn't standard or normal to you doesn't mean it's not being done in the business world SOMEWHERE. I love to do things that others aren't doing it's where the real money is made. I'm not an employee, I don't do the same shit over and over for a company. I solve unique problems, and optimize systems to perform at there best.... so yes I'm constantly tweaking, and changing packages/installs regularly based on client/performance/project/whatever, and want to test/dev locally.

What you just said NOT to do, is exactly WHAT I do. I solve CLIENT SPECIFIC problems, I fix things for them SPECIFICALLY. I don't have GENERIC SHIT sitting on the shelf to stuff at them. But I sure do have copies of their VMs on a scheduler, as well as other important stuff. Was that example harsh? Sure, but so was you TELLING ME how to do it because that's how it's done, I don't mind the advice but don't go overboard with the rules ;) lol.

We obviously use VMs for different purposes, and very little of what I do is repetitive VMs other than the ones for specific tasks, which is what you are getting at and I get that 100%. But that's not the point of this thread, and NOT the question I asked.

Like I said, I've been using VMs since they became a "thing" but only recently have I started playing around with local hosts and various hypervisors from the ground up to expand my knowledge and better expand my business.

And by "tweaking and configuring" VMs... I mean exactly that. Most clients don't use the same EVERYTHING as other clients but a baseline template is used... but from there I tweak, and I'd rather do it local/travel/whatever than rely on internet connection to my dev-host at home.

I can see where you're coming from with Workstation and developing on the 'actual' machine to be sure/safe, but your other problems... you're just projecting those problems onto myself and others, we may have better workstations. I know I built mine specifically for testing VMs and development. I appreciate the info you shared and your opinions but could do without the "this way" talk, that's exactly how people get in holes, and it's not exactly good for business ;)
Click to expand...


Wow ... I'm not the only one this "thread shift" happens too. :)

Ever watch the "Extreme Log Cabins" show (on HGTV IIRC).

Sometimes they build the cabins completely from scratch on one site,
tear it down, move the materials to the final site and rebuild it again in that final site.

You ask yourself .."why the hell do they do all that work _twice_!!? Why not just build it at the final site to begin with???".

...lol...damn ...lost my thought ...aging sucks.

Anyhow when I saw the OP I thought the same thing ..doing work twice and why not just build the VM within ESXi, whether from template or not, if the final destination is an ESXi server.

I have used VMware Workstation a time or two in that fashion because I was off grid playing with a VM I later wanted on an ESXi host. That is really the only scenario I have done it in.

So I can see if your job is going from customer to customer pushing a special VM build to those customers ... makes sense to do it that way (sometimes customers won't give you out of business hours to environment and you like to work through the night on a VM project.

anyhow ...i see both sides and you can't tell posters not to impose rules and turn around
and impose rules on them :p
 
I see if from both directions. I work at a small shop and most of our customers don't have a full suite of VMware products (or Windows for that), so running this and that to do X and Y is not going to happen. In a Med+ environment I totally agree with Iop. Standardization must be a key thing. I've see it done the incorrect way and boy what a mess that is. My my usage of Workstation for a client specific build has been less than 5 times so far and I was traveling so no access to their server.
 
peanuthead said:
I see if from both directions. I work at a small shop and most of our customers don't have a full suite of VMware products (or Windows for that), so running this and that to do X and Y is not going to happen. In a Med+ environment I totally agree with Iop. Standardization must be a key thing. I've see it done the incorrect way and boy what a mess that is. My my usage of Workstation for a client specific build has been less than 5 times so far and I was traveling so no access to their server.
Click to expand...

You know, I suspect strongly Todd and I are talking about very different scales too.

I was thinking about this last night after posting, and if I was working with a small shop where the builds don't happen often and VMs tend to have very long lifetimes, then building something locally, pushing it, and being done may make sense.

Almost all my recent experience has been in places where that won't fly though; Most VM counts at my recent customers started at around 2000 VMs on 200 hosts, and went up drastically from there. In places like that, you ~can't~ build bespoke VMs, because it'd be a management nightmare. In fact, even manually cloning templates to build workloads doesn't fly well. I can't tune SQL or JREs for NUMA affinity and cross-die cache access when I don't have a host at home with 512G of RAM across 4 sockets - it's simply impossible.
 
lopoetve said:
You know, I suspect strongly Todd and I are talking about very different scales too.

I was thinking about this last night after posting, and if I was working with a small shop where the builds don't happen often and VMs tend to have very long lifetimes, then building something locally, pushing it, and being done may make sense.

Almost all my recent experience has been in places where that won't fly though; Most VM counts at my recent customers started at around 2000 VMs on 200 hosts, and went up drastically from there. In places like that, you ~can't~ build bespoke VMs, because it'd be a management nightmare. In fact, even manually cloning templates to build workloads doesn't fly well. I can't tune SQL or JREs for NUMA affinity and cross-die cache access when I don't have a host at home with 512G of RAM across 4 sockets - it's simply impossible.
Click to expand...

Bingo, that's where the difference is. He is probably talking about clients utilizing a much smaller amount (i.e., 10 VMs). He did hint that it was a very specific configuration.
 
Great!

I think the last few threads cleared it up.

Nothing we do is standard, or to scale for clients. The largest scale work we do is for internal custom software, and in that case I've only scaled up to 50 VMs on XEN. Sure we work with customers doing millions in sales that have 0 owned hypervisor hosts, but that doesn't mean they don't utilize bare-metal, the VMs elsewhere or on an as-needed basis from providers who lease. (We're talking EC2, LINODE, and other "web" based VMs that I deal with 90% of the time.)

We're heading in a direction of wanting to manage our own VMs in house as it becomes more cost affective to do so based on specific projects we're working on in-house. (And because we recently got a bunch of dual E5 systems for dev work) Does that mean VMWARE, XEN or ??? Not sure yet, we're ideally looking for something that our software/SaaS can interact with for auto-scaling/management of the VMs from directly within our software. I believe XEN has some APIs for this, I haven't gotten that farin ESXI host stuff yet. Leasing VM's for our purpose is stupid expensive as we max them out 100%, so we've kept with baremetal the last 15 years or so for our web business.

We have some other clients we hope to get running VMWARE stuff locally, but even small/med biz with 1-3 hosts with 5-10 VMs each, it's big $$ for them up front.

Thanks for clarifications, advice and general thoughts on the matter. I'm sure I'll have more questions once I get to getting into it more.
 
You don't develop a virtual machine, you develop an application. If you leave your mindset in that realm you will be doing menial work of manually installing software for the rest of your career.

Consider finding a proper configuration management tool and deployment methodology. The scale of the customer can define which of those tools is right to use, but they should not be excluded altogether.

And as far as the 'tweaking' and 'hands-on-testing'--stop wasting time. You could do most of that by changing the line in one config file.

...and I really really hope you're using an automated testing suite...
 
You must log in or register to reply here.
Back
Top