Martytoof posted:

Here's a (not so) small excerpt from my vmkernel.log. Definitely seems like there's something going on. Still working on interpreting it.

http://pastebin.com/5910mKX2

evol262 posted:

Basically because non-accelerated NICs (e1000, rt8139, etc) clog up the system looking for interrupts and are less performant on guests. Not because they cause panics and break functionality. They shouldn't. File bugs if so

Geisladisk posted:

So, in relation to my previous post - I'm having serious performance issues on my Windows 7 VM. I tried to fix it by adding more cores (see above). That didn't work.

This is what process manager looks like a couple of minutes after startup. I started the computer, and did nothing except open process manager:



This is a minute or so of doing absolutely nothing. Right clicking on my desktop would bring CPU on all four cores to 70% for a second or two.

There's nothing out of the ordinary running. The other VMs on the host (10 of them) are running smoothly and are responsive while this is going on. The host machine (Ubuntu 14) is responsive while this is going on.

Any suggestions?

evol262 posted:

"This is a known issue affecting..."
"This issue is resolved in:"

This is exactly how bug errata is worded. It's a bug, and it got fixed, probably because somebody reported issues.

Your point is what?

Thanks Ants posted:

Why were you even doing the whole VDI thing if you have real PC hardware on the clients and the ability to manage them effectively?

stupid things three has said posted:

Well, they've already basically killed the Windows client (new features are web client only), so I imagine the Windows server will go soon. They'd need to spend the next year fixing the VCSA as it exists now, though.

I would only use a dvSwitch if I planned on using the features specific to it (inbound traffic shaping, private VLANs, LACP, etc). I think they add unnecessary complexity otherwise.

All EUC/VDI stuff is buggy. VMware View is no better from a polish standpoint than Citrix.

I can guarantee most of you did things differently 6 years ago. Virtualization was still fairly new in 2008. Critiquing and/or using a 6 year old blog post is really dumb.

three posted:

DevNull posted:

This should help cool tempers: https://www.youtube.com/watch?v=fruwgLHCaCQ

three posted:

Try to find a reference case of any company successfully using ThinApp as their primary software distribution tool, or as a replacement for XenApp.

three posted:

That's via Horizon View. You wanted to do it to physical machines. Your opinion isn't going to change, so I'm not going to keep trying to tell you that ThinApp to physical is not a great solution given all of the options available. Go for it. It's your environment. I'm sure you can make it 'work'.

Maybe if you do a good job you can move to the actual IT team and not have to try to circumvent the operational rules with bad software.

Zero VGS posted:

I know my opinion isn't the popular one and I don't want to necro this debate again, but I've never seen Windows servers never manage the sheer uptime of running DHCP on say, Cisco switches. Plus you do need to get CALs when you serve off Windows. I do see the merits of both sides, I just sleep better with DHCP on something embedded. For the record, at this place I moved DHCP from a Win2003 Celeron onto to a pair of active-active Peplink Balance routers that are also bonding our three ISPs.

bull3964 posted:

We're going to be changing up the network adapters in our VMWare hosts soon and I'm trying to clarify a few things relating to MTU.

We have jumbo frames enabled on our VMotion network and iSCSI network, but not for general virtual machine networks or management network.

Up until now, everything has had their own vSwitch since we were using 12 1gb adapters per host. All functions were segregated. We will be moving to 4x 10gb adapters so things will be sharing.

So, if I wanted Management, VMotion, and Virutal Machine traffic to be on the same vSwitch (sharing two of the 10gb adapters) then I would set the vSwitch to 9000 MTU, VMKernel Ports for VMotion to 9000 MTU, Management VMKernel ports to 1500 MTU, and the Virtual Machine Port groups will use whatever MTU the guest adapters in the virtual machines are configured with?

That last bit is what tripped me up since there is no MTU configuration option for the Virtual Machine Port Groups in VMWare, but I guess it makes sense that it's up to the guest's setting.

Internet Explorer posted:

I feel as the thread's resident Citrix guy I should have responded to this already. I'm feeling really guilty for having not have responded. Did you get this sorted? If not, I should be a leader to give you a hand. If I remember correctly all you rally need to do is rekey your cert on vCenter, export it, then import it on your DDCs, but it's been a few months.

Also, play around with Provisioning Server if you get the chance. It's kind of the red headed stepchild but it is quite awesome compared to Machine Creation Services.

adorai posted:

Somehow I doubt FC would have made this any better.

Internet Explorer posted:

I haven't heard of this and couldn't find any evidence of it in a quick glance, but that doesn't mean a whole lot as I try to talk to Microsoft as little as possible. Are you sure that this isn't specifically VMDKs on NFS?


Every vendor will tell you that their way is the best way to do it. I am all for following best practices, but at some point knowing when not to follow best practices is where the value is.

Unless you are seriously pushing your hardware or have very specific design considerations, I would run SQL / Exchange / File Servers in a VMDK. The added flexibility and maintainability is well worth it. Being able to use snapshots and have them be consistent, being able to use storage vMotion, plus a bunch of other factors.