USB over Network allows USB devices to be connected to a physical computer and then mapped into virtual machines over the standard TCP/IP network. For example, suppose that a virtual machine needs access to a high-speed scanner that connects via USB. With USB over Network, the scanner can be connected to a physical computer somewhere on the network and then mapped into the virtual machine. The physical computer where the scanner is connected would use the USB over Network Server and the virtual machine would be installed with the USB over Network Client. The solution ends up presenting the high-speed scanner to the virtual machine as if it were truly a local device.
Lost Creations viplugins
On the smaller scale, but high up on the functionality scale are the products created by a company named Lost Creations. From their web site at www.lostcreations.com (or www.viplugins.com) you will find some very useful plugins for VirtualCenter. Among their available plugins you will find:
♦ SVMotion 0.4.4 — This VI plugin, perhaps the most useful of all, allows VMware administrators to invoke storage VMotion (SVMotion) events from within VirtualCenter. The first release of Storage VMotion, available at the time of writing, required a command line execution using the svmotion.pl utility.
♦ Add Port Groups 0.1.0 — This plugin facilitates managing virtual networks across multiple ESX Server hosts. It allows for the creation of multiple port groups (the vSwitch must exist) of any type on a number of ESX servers and virtual switches at once, thus eliminating the need to recreate on a host-by-host basis.
♦ RDP 1.0.1 — This tool builds Remote Desktop access directly into the Virtual Infrastructure client connection. The right-click context menu of a virtual machine includes an option to initiate an RDP session.
♦ Console 0.1.5 — This plugin adds a console tab to the details pane of an ESX Server host. Similar to the console tab natively available for virtual machine this plugin adds direct console access to an ESX Server from within the Virtual Infrastructure client.
♦ Invoke 0.1.7 — This plugin provides a high level of customization by allowing an administrator to invoke third-party applications from within the Virtual Infrastructure client connection. It can even pass the existing session cookie to the third-party application. This opens up the VI Client to a new world of integration with perl, Java, or .NET applications.
Appendix D VMware Infrastructure 3 Best Practices
This appendix serves as an overview of the many design, deployment, management, and monitoring concepts discussed throughout the book. It can be used as a quick reference for any phase of your virtual infrastructure deployment. The appendix is also meant as a review of the material we covered, with a focus on the concepts of VMware Infrastructure 3 (VI3) that are commonly discussed in the world of virtualization management. By reviewing the appendix, you can gauge your level of fluency with the concepts we've discussed. If you're unsure of any of the best practices outlined here, you can revisit the various sections of the book for more details about that particular best practice.
Installation Best Practices
The following best practice suggestions are derived from the full details outlined in Chapters 2 and 13.
♦ Review your architecture needs to determine if ESX Server 3.5 or ESXi is the right foundation for your virtual infrastructure. Identify the answers to questions like:
♦ Do I have a need for the console operating system?
♦ Do I have a need to minimize the footprint on the physical server?
♦ Do I want to install any third-party applications that require the service console?
♦ Always consult the ESX Server compatibility guides before purchasing any new hardware. Even if you are successful at installing on unsupported hardware, be aware that using hardware not listed on the compatibility guides will force any support calls to end abruptly. Ensure that you review the appropriate compatibility guide for the product you have chosen to install.
♦ Plan the Service Console management methods before installing. Identify the answers to questions like:
♦ Will the Service Console be on a dedicated management network or on the same network as virtual machines?
♦ Will I be using VLANs or physical hardware to segment the Service Console?
♦ How will I provide redundancy for the Service Console communication?
♦ If you're installing ESX Server 3.5, construct a Service Console security plan. Ensure limited access to the Service Console by minimizing the number of administrators with local user accounts or knowledge of the root password.
♦ Create user accounts for each administrative user who requires direct access to an ESX Server host.
♦ Establish strong user account policies in the Service Console by integrating ESX Server with Active Directory or by deploying a Linux-based security module.
♦ Establish growth projections and plan the ESX Server partition strategy accordingly.
♦ Increase /root partition size to provide ample room for growth and/or the installation of third-party applications. If the root of the file system runs out of space, there will most certainly be issues to address.
♦ Increase /swap partition size to address any projected increases in the amount of RAM provided to the Service Console. The /swap should be twice the amount of RAM that will be allocated to the Service Console.
♦ Change /var/log to /var and increase partition size to provide ample room for logs and the ESX Server patch management process that writes to the /var directory during the process.
♦ Unless performing a boot from SAN, detach ESX Server hosts from the external storage devices to prevent overwriting existing data. At minimum, don't present LUNs to a new ESX Server host until the installation is complete.
♦ When reinstalling ESX Server on a physical server, be careful not to initiate LUNs with existing data. Once again, disconnecting a host from the SAN during the reinstall process will eliminate the threat of erasing data.
♦ Configure a time synchronization strategy that synchronizes all ESX Server hosts with the same external time server.
♦ Ensure the security of console access by guaranteeing the physical security of the box. If the server is configured with a remote console adapter, like the Dell Remote Access Controller (DRAC), ensure the default password has been changed and that the DRAC network is not readily accessible to other network segments.
Virtual Networking Best Practices
The configuration details regarding the virtual networking best practices shown here can be found in Chapter 3.
♦ Plan the virtual-to-physical networking integration.
♦ Maximize the number of physical network adapters (Ethernet ports) to provide flexibility in the virtual networking architecture.
♦ Separate Service Console, iSCSI, NAS, VMotion, and virtual machine traffic across different physical networks pending the availability of network adapters or use a VLAN architecture to segment the traffic.
♦ Create virtual switches with VLAN IDs to provide security, segmentation, and scalability to the virtual switching architecture.
♦ Construct a virtual networking security policy for virtual switches, ports, and port groups.
♦ Create port groups for security, traffic shaping, or VLAN tagging.
♦ For optimal security, configure the virtual switch properties with the following settings:
♦ Promiscuous mode: Reject