Showing posts with label virtualization. Show all posts
Showing posts with label virtualization. Show all posts

Wednesday, September 25, 2013

Don't be scared of virtualization

Occasionally I talk with an IT guy who is scared to death of virtualization. Why the fear? Well the typical answer I get is that "it's complicated" or "expensive" or "I have no experience with it; going forward with it would be risky." If you're a virtualization tech of any stripe you'll know these worries can be easily erased. My own work experience with Hyper-V is a great answer to these techs who are scared (no offense) of virtualization. Why do I say don't be scared? I say don't be scared of virtualization because 1) you have no reason to be and 2) virtualization is super helpful for the most ordinary of IT projects.

At work we needed to implement Server 2008 R2's RDWeb services to enable our work application to be available to users who are away from our main office and for users who needed to access the application when they're sick, on vacation, etc. When the concern was approached to me, I immediately thought of R2's RDWeb services and pitched the idea to a group of people who were not interested in buying a new server. They assumed to use the RDWeb service we would need to purchase new hardware and that just wasn't going to happen (I work for local government and money is tight!). I told them they didn't have to worry about purchasing new hardware because of Hyper-V! We were limited to the 2008 version of Hyper-V, so we aren't able to use features like dynamic memory and bandwidth management but the point I made to them and want to make here is that even 2008's Hyper-V can make the simplest of IT projects, e.g. rolling out RDWeb, even simpler and much, much cheaper than going with new hardware. The only purchase made was five Remote Desktop Services CALs! The rest of the project requirements were already owned by us which was awesome. If we didn't go the virtualization route we would have made a lot of purchases in hardware. So I added the Hyper-V role to an existing Windows Server 2008 machine, configured the RDWeb virtual machine, installed a copy of Windows Server 2008 R2 on the VM, installed and configured RDWeb on the virtual machine, made the necessary configurations in our Sonicwall TZ210 and then we were all set. Virtualization made that project so much easier than the alternative which is to buy new hardware, make room for that hardware, oh and convince the treasurer and company to make those purchases. For us, the project only cost us a couple of hundred dollars and RDWeb has helped us out a lot. Virtualizaton was the obvious route to take.

Don't be scared of virtualization! Implementing Hyper-V, Citrix, or VMWare doesn't mean you have to setup live migrations, virtual storage, virtual networks, VDI, or whatever else is intimidating to you; all it can mean is that you're going to use a virtual machine instead of a physical machine for your project. Try it out, even if it's in a lab at first. You can download trial copies of Server 2012 and Windows 8 to tinker around with virtualization if you haven't yet. Keith Mayer has awesome lab exercises for you to try and I know from personal experience that his lab exercises are awesome because I've used them multiple times! Again, don't be scared of virtualization because the benefits and range of uses are too great for you to not use because you're a little intimidated. 

Monday, March 18, 2013

Hyper-V 3.0 Best Practices Checklist

The Ask PFE Platforms blog has an excellent post on Windows Server 2012 Hyper-V best practices and it's actually in-depth. I'm only sharing the "general" section for the host not the vms because there are many things to checkoff your roll-out list before you even get to the "deep" things of rolling out a Hyper-V environment.

Excerpt from the blog post:

GENERAL (HOST):
⎕ Use Server Core, if possible, to reduce OS overhead, reduce potential attack surface, and to minimize reboots (due to fewer software updates).

⎕ Ensure hosts are up-to-date with recommended Microsoft updates, to ensure critical patches and updates – addressing security concerns or fixes to the core OS – are applied.
⎕ Ensure all applicable Hyper-V hotfixes and Cluster hotfixes (if applicable) have been applied. Review the following sites and compare it to your environment, since not all hotfixes will be applicable:

· Update List for Windows Server 2012 Hyper-V: http://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx

· List of Failover Cluster Hotfixes: http://social.technet.microsoft.com/wiki/contents/articles/15577.list-of-failover-cluster-hotfixes-for-windows-server-2012.aspx
⎕ Ensure hosts have the latest BIOS version, as well as other hardware devices (such as Synthetic Fibre Channel, NIC’s, etc.), to address any known issues/supportability
⎕ Host should be domain joined, unless security standards dictate otherwise. Doing so makes it possible to centralize the management of policies for identity, security, and auditing. Additionally, hosts must be domain joined before you can create a Hyper-V High-Availability Cluster.

· For more information: http://technet.microsoft.com/en-us/library/ee941123(v=WS.10).aspx
⎕ RDP Printer Mapping should be disabled on hosts, to remove any chance of a printer driver causing instability issues on the host machine.

  • Preferred method: Use Group Policy with host servers in their own separate OU
    • Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Printer Redirection –> Do not allow client printer redirection –> Set to "Enabled
⎕ Do not install any other Roles on a host besides the Hyper-V role and the Remote Desktop Services roles (if VDI will be used on the host).

  • When the Hyper-V role is installed, the host OS becomes the "Parent Partition" (a quasi-virtual machine), and the Hypervisor partition is placed between the parent partition and the hardware. As a result, it is not recommended to install additional (non-Hyper-V and/or VDI related) roles.
⎕ The only Features that should be installed on the host are: Failover Cluster Manager (if host will become part of a cluster), Multipath I/O (if host will be connecting to an iSCSI SAN, Spaces and/or Fibre Channel), or Remote Desktop Services if VDI is being used. (See explanation above for reasons why installing additional features is not recommended.)
⎕ Anti-virus software should exclude Hyper-V specific files using the Hyper-V: Antivirus Exclusions for Hyper-V Hosts article, namely:

    • All folders containing VHD, VHDX, AVHD, VSV and ISO files
    • Default virtual machine configuration directory, if used (C:\ProgramData\Microsoft\Windows\Hyper-V)
    • Default snapshot files directory, if used (%systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots)
    • Custom virtual machine configuration directories, if applicable
    • Default virtual hard disk drive directory
    • Custom virtual hard disk drive directories
    • Snapshot directories
    • Vmms.exe (Note: May need to be configured as process exclusions within the antivirus software)
    • Vmwp.exe (Note: May need to be configured as process exclusions within the antivirus software)
    • Additionally, when you use Cluster Shared Volumes, exclude the CSV path "C:\ClusterStorage" and all its subdirectories.
  • For more information: http://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx
⎕ Default path for Virtual Hard Disks (VHD/VHDX) should be set to a non-system drive, due to this can cause disk latency as well as create the potential for the host running out of disk space.
⎕ If you choose to save the VM state as the Automatic Stop Action, the default virtual machine path should be set to a non-system drive, due to the creation of a .bin file is created that matches the size of memory reserved for the virtual machine.  A .vsv file may also be created in the same location as the .bin file, adding to disk space used for each VM. (The default path is: C:\ProgramData\Microsoft\Windows\Hyper-V.)

⎕ If you are using iSCSI: In Windows Firewall with Advanced Security, enable iSCSI Service (TCP-In) for Inbound and iSCSI Service (TCP-Out) for outbound in Firewall settings on each host, to allow iSCSI traffic to pass to and from host and SAN device. Not enabling these rules will prevent iSCSI communication.

To set the iSCSI firewall rules via netsh, you can use the following command:

Netsh advfirewall firewall set rule group=”iSCSI Service” new enable=yes

⎕ Periodically run performance counters against the host, to ensure optimal performance.

  • Recommend using the Hyper-V performance counter that can be extracted from the (free) Codeplex PAL application:
  • Install PAL on a workstation and open it, then click on the Threshold File tab.
    • Select "Microsoft Windows Server 2012 Hyper-V" from the Threshold file title, then choose Export to Perfmon template file. Save the XML file to a location accessible to the Hyper-V host.
  • Next, on the host, open Server Manager –> Tool –> Performance Monitor
  • In Performance Monitor, click on Data Collector Sets –> User Defined. Right click on User Defined and choose New –> Data Collector Set. Name the collector set "Hyper-V Performance Counter Set" and select Create from a template (Recommended) then choose Next. On the next screen, select Browse and then locate the XML file you exported from the PAL application. Once done, this will show up in your User Defined Data Collector Sets.
  • Run these counters in Performance Monitor for 30 minutes to 1 hour (during high usage times) and look for disk latency, memory and CPU issues, etc.
Check out the entire thing and bookmark it! :D Click here.

Monday, January 7, 2013

10 Essentials Skills for Hyper-V 3.0

If you're interested learning 10 skills for using the next generation of hyper-v, I highly recommend this webinar by Brien Posey from Veeam. 


Wednesday, December 5, 2012

Can't Change Screen Resolution During Remote Session

A lot of screen resolution problems lately. This one though is a problem a remote user had yesterday during her remote session to a vm she logs into at our main site. Her setup is the following: vpn to our main site, rdp to virtual machine. At her remote site, the power user there installed new monitors for clients. The new monitors are wide screen monitors, replacing their old square monitors. This client in particular didn't like the new monitors because of the small display size that wide screen monitors typically default to. The power user at the site customized the user's desktop very well just by changing the display size of the screen to %135.

Yesterday, I got a call from the power user telling me the client wasn't happy with the display size for her remote session, especially since she couldn't customize the screen resolution or display size (both are grayed out during a remote session). The remote user was trashing the vpn connection, our software, and everything else that wasn't related to the actual issue. The power user said he couldn't figure out why they couldn't change the display settings. He thought it may have been a privilege issue, but that's not the reason. From what I know, display settings cannot be changed during a remote session.

To fix the issue I went to our server, logged into the virtual machine the remote users logs into and changed the display size to 150%. She was happy, the power user was happy; it was good.

There might be a workaround, but I don't know of one. I'm not far from the physical server, so the best solution for me was to go to the server and change the display size for the vm, call the power user and ask him how the new size looked.

If you know of a solution for changing the display size of a pc during a remote session comment below.