3
Configure console login password on Cisco switch
0 Comments | Posted by admin in Uncategorized
Cisco devices allow password protection of console access. This recipe describes configuring the use of a password to protect the console of a Cisco switch.
To set the console password to keepout, enter the following commands from global configuration mode:
line console 0
password keepout
login
The login statement enables logins from the console.
NewSID v4.10
Published: November 1, 2006
Note: NewSID has been retired and is no longer available for download. Please see Mark Russinovich’s blog post: NewSID Retirement and the Machine SID Duplication Myth
IMPORTANT:
Regarding SIDs, Microsoft does not support images that are prepared using NewSID, we only support images that are prepared using SysPrep. Microsoft has not tested NewSID for all deployment cloning options.
For more information on Microsoft’s official policy, please see the following Knowledge Base article:
Introduction
Many organizations use disk image cloning to perform mass rollouts of Windows. This technique involves copying the disks of a fully installed and configured Windows computer onto the disk drives of other computers. These other computers effectively appear to have been through the same install process, and are immediately available for use.
While this method saves hours of work and hassle over other rollout approaches, it has the major problem that every cloned system has an identical Computer Security Identifier (SID). This fact compromises security in Workgroup environments, and removable media security can also be compromised in networks with multiple identical computer SIDs.
Demand from the Windows community has lead several companies to develop programs that can change a computer’s SID after a system has been cloned. However, Symantec’s SID Changer andSymantec’s Ghost Walker are only sold as part of each company’s high-end product. Further, they both run from a DOS command prompt (Altiris’ changer is similar to NewSID).
NewSID is a program we developed that changes a computer’s SID. It is free and is a Win32 program, meaning that it can easily be run on systems that have been previously cloned.
Please read this entire article before you use this program.
Version Information:
- Version 4.0 introduces support for Windows XP and .NET Server, a wizard-style interface, allows you to specify the SID that you want applied, Registry compaction and also the option to rename a computer (which results in a change of both NetBIOS and DNS names).
- Version 3.02 corrects a bug where NewSid would not correctly copy default values with invalid value types when renaming a key with an old SID to a new SID. NT actually makes use of such invalid values at certain times in the SAM. The symptom of this bug was error messages reporting access denied when account information was updated by an authorized user.
- Version 3.01 adds a work-around for an inaccessible Registry key that is created by Microsoft Transaction Server. Without the work-around NewSID would quit prematurely.
- Version 3.0 introduces a SID-sync feature that directs NewSID to obtain a SID to apply from another computer.
- Version 2.0 has an automated-mode option, and let’s you change the computer name as well.
- Version 1.2 fixes a bug in that was introduced in 1.1 where some file system security descriptors were not updated.
- Version 1.1 corrects a relatively minor bug that affected only certain installations. It also has been updated to change SIDs associated with the permission settings of file and printer shares.
Cloning and Alternate Rollout Methods
One of the most popular ways of performing mass Windows rollouts (typically hundreds of computers) in corporate environments is based on the technique of disk cloning. A system administrator installs the base operating system and add-on software used in the company on a template computer. After configuring the machine for operation in the company network, automated disk or system duplication tools (such as Symantec’sGhost, PowerQuest’sImage Drive, and Altiris’RapiDeploy) are used to copy the template computer’s drives onto tens or hundreds of computers. These clones are then given final tweaks, such as the assignment of unique names, and then used by company employees.
Another popular way of rolling out is by using the Microsoft sysdiff utility (part of the Windows Resource Kit). This tool requires that the system administrator perform a full install (usually a scripted unattended installation) on each computer, and then sysdiff automates the application of add-on software install images.
Because the installation is skipped, and because disk sector copying is more efficient than file copying, a cloned-based rollout can save dozens of hours over a comparable sysdiff install. In addition, the system administrator does not have to learn how to use unattended install or sysdiff, or create and debug install scripts. This alone saves hours of work.
The SID Duplication Problem
The problem with cloning is that it is only supported by Microsoft in a very limited sense. Microsoft has stated that cloning systems is only supported if it is done before the GUI portion of Windows Setup has been reached. When the install reaches this point the computer is assigned a name and a unique computer SID. If a system is cloned after this step the cloned machines will all have identical computer SIDs. Note that just changing the computer name or adding the computer to a different domain does not change the computer SID. Changing the name or domain only changes the domain SID if the computer was previously associated with a domain.
To understand the problem that cloning can cause, it is first necessary to understand how individual local accounts on a computer are assigned SIDs. The SIDs of local accounts consist of the computer’s SID and an appended RID (Relative Identifier). The RID starts at a fixed value, and is increased by one for each account created. This means that the second account on one computer, for example, will be given the same RID as the second account on a clone. The result is that both accounts have the same SID.
Duplicate SIDs aren’t an issue in a Domain-based environment since domain accounts have SID’s based on the Domain SID. But, according to Microsoft Knowledge Base article Q162001, “Do Not Disk Duplicate Installed Versions of Windows NT”, in a Workgroup environment security is based on local account SIDs. Thus, if two computers have users with the same SID, the Workgroup will not be able to distinguish between the users. All resources, including files and Registry keys, that one user has access to, the other will as well.
Another instance where duplicate SIDs can cause problems is where there is removable media formated with NTFS, and local account security attributes are applied to files and directories. If such a media is moved to a different computer that has the same SID, then local accounts that otherwise would not be able to access the files might be able to if their account IDs happened to match those in the security attributes. This is not be possible if computers have different SIDs.
An article Mark has written, entitled “NT Rollout Options,” was published in the June issue of Windows NT Magazine. It discusses the duplicate SID issue in more detail, and presents Microsoft’s official stance on cloning. To see if you have a duplicate SID issue on your network, use PsGetSid to display machine SIDs.
NewSID
NewSID is a program we developed to change a computer’s SID. It first generates a random SID for the computer, and proceeds to update instances of the existing computer SID it finds in the Registry and in file security descriptors, replacing occurrences with the new SID. NewSID requires administrative privileges to run. It has two functions: changing the SID, and changing the computer name.
To use NewSID’s auto-run option, specify “/a” on the command line. You can also direct it to automatically change the computer’s name by including the new name after the “/a” switch. For example:
newsid /a [newname]
Would have NewSID run without prompting, change the computer name to “newname” and have it reboot the computer if everything goes okay.
Note: If the system on which you wish to run NewSID is running IISAdmin you must stop the IISAdmin service before running NewSID. Use this command to stop the IISAdmin service: net stop iisadmin /y
NewSID’s SID-synchronizing feature that allows you to specify that, instead of randomly generating one, the new SID should be obtained from a different computer. This functionality makes it possible to move a Backup Domain Controller (BDC) to a new Domain, since a BDC’s relationship to a Domain is identified by it having the same computer SID as the other Domain Controllers (DCs). Simply choose the “Synchronize SID” button and enter the target computer’s name. You must have permissions to change the security settings of the target computer’s Registry keys, which typically means that you must be logged in as a domain administrator to use this feature.
Note that when you run NewSID that the size of the Registry will grow, so make sure that the maximum Registry size will accomodate growth. We have found that this growth has no perceptible impact on system performace. The reason the Registry grows is that it becomes fragmented as temporary security settings are applied by NewSID. When the settings are removed the Registry is not compacted.
Important: Note that while we have thoroughly tested NewSID, you must use it at your own risk. As with any software that changes file and Registry settings, it is highly recommended that you completely back-up your computer before running NewSID.
Moving a BDC
Here are the steps you should follow when you want to move a BDC from one domain to another:
- Boot up the BDC you want to move and log in. Use NewSID to synchronize the SID of the BDC with the PDC of the domain to which you wish to move the BDC.
- Reboot the system for which you changed the SID (the BDC). Since the domain the BDC is now associated with already has an active PDC, it will boot as a BDC in its new domain.
- The BDC will show up as a workstation in Server Manager, so use the “Add to Domain” button to add the BDC to its new domain. Be sure to specify the BDC radio button when adding.
How it Works
NewSID starts by reading the existing computer SID. A computer’s SID is stored in the Registry’s SECURITY hive under SECURITY\SAM\Domains\Account. This key has a value named F and a value named V. The V value is a binary value that has the computer SID embedded within it at the end of its data. NewSID ensures that this SID is in a standard format (3 32-bit subauthorities preceded by three 32-bit authority fields).
Next, NewSID generates a new random SID for the computer. NewSID’s generation takes great pains to create a truly random 96-bit value, which replaces the 96-bits of the 3 subauthority values that make up a computer SID.
Three phases to the computer SID replacement follow. In the first phase, the SECURITY and SAM Registry hives are scanned for occurrences of the old computer SID in key values, as well as the names of the keys. When the SID is found in a value it is replaced with the new computer SID, and when the SID is found in a name, the key and its subkeys are copied to a new subkey that has the same name except with the new SID replacing the old.
The final two phases involve updating security descriptors. Registry keys and NTFS files have security associated with them. Security descriptors consist of an entry that identifies which account owns the resource, which group is the primary group owner, an optional list of entries that specify actions permitted by users or groups (known as the Discretionary Access Control List – DACL), and an optional list of entries that specify which actions performed by certain users or groups will generate entries in the system Event Log (System Access Control List – SACL). A user or a group is identified in these security descriptors with their SIDs, and as I stated earlier, local user accounts (other than the built-in accounts such as Administrator, Guest, and so on) have their SIDs made up of the computer SID plus a RID.
The first part of security descriptor updates occurs on all NTFS file system files on the computer. Every security descriptor is scanned for occurrences of the computer SID. When NewSID finds one, it replaces it with the new computer SID.
The second part of security descriptor updates is performed on the Registry. First, NewSID must make sure that it scans all hives, not just those that are loaded. Every user account has a Registry hive that is loaded as HKEY_CURRENT_USER when the user is logged in, but remains on disk in the user’s profile directory when they are not. NewSID identifies the locations of all user hive locations by enumerating the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList key, which points at the directories in which they are stored. It then loads them into the Registry using RegLoadKey under HKEY_LOCAL_MACHINE and scans the entire Registry, examining each security descriptor in search of the old computer SID. Updates are performed the same as for files, and when its done NewSID unloads the user hives it loaded. As a final step NewSID scans the HKEY_USERS key, which contains the hive of the currently logged-in user as well as the .Default hive. This is necessary because a hive can’t be loaded twice, so the logged-in user hive won’t be loaded into HKEY_LOCAL_MACHINE when NewSID is loading other user hives.
Finally, NewSID must update the ProfileList subkeys to refer to the new account SIDs. This step is necessary to have Windows NT correctly associate profiles with the user accounts after the account SIDs are changed to reflect the new computer SID.
NewSID ensures that it can access and modify every file and Registry key in the system by giving itself the following privileges: System, Backup, Restore and Take Ownership.
| How to configure an authoritative time server in Windows Server
Windows includes W32Time, the Time Service tool that is required by the Kerberos… Windows includes W32Time, the Time Service tool that is required by the Kerberos authentication protocol. The purpose of the Windows Time service is to make sure that all computers that are running Microsoft Windows 2000 or later versions in an organization use a common time. To guarantee appropriate common time usage, the Windows Time service uses a hierarchical relationship that controls authority, and the Windows Time service does not permit loops. By default, Windows-based computers use the following hierarchy: All client desktop computers nominate the authenticating domain controller as their in-bound time partner. All member servers follow the same process that client desktop computers follow. All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner. All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner. In this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization. We highly recommend that you configure the authoritative time server to gather the time from a hardware source. When you configure the authoritative time server to sync with an Internet time source, there is no authentication. We also recommend that you reduce your time correction settings for your servers and stand-alone clients. These recommendations provide more accuracy and security to your domain. Configuring the Windows Time service to use an internal hardware clock Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base: 322756 (http://support.microsoft.com/kb/322756/ ) How to back up and restore the registry in Windows To configure the PDC master without using an external time source, change the announce flag on the PDC master. The PDC master is the server that holds the forest root PDC master role for the domain. This configuration forces the PDC master to announce itself as a reliable time source and uses the built-in complementary metal oxide semiconductor (CMOS) clock. To configure the PDC master by using an internal hardware clock, follow these steps:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
net stop w32time && net start w32time Note The PDC master must not be configured to synchronize with itself. For more information about why the PDC master must not be configured to synchronize with itself, visit the following Web site to view Request For Comment (RFC) 1305: http://www.rfc-editor.org/ (http://www.rfc-editor.org/) If the PDC master is configured to synchronize with itself, the following events are logged in the System log: Event Type: Information Event Type: Warning Event Type: Error When the PDC master runs without using an external time source, the following event is logged in the Application log: Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient. This text is a reminder to use an external time source, and it can be ignored. Configuring the Windows Time service to use an external time source To configure an internal time server to synchronize with an external time source, follow these steps:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval
. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxPosPhaseCorrection
net stop w32time && net start w32time Troubleshooting For the Windows Time service to function correctly, the networking infrastructure must function correctly. The most common problems that affect the Windows Time service include the following:
We recommend that you use the Netdiag.exe utility to troubleshoot network-related issues. Netdiag.exe is part of the Windows Server 2003 Support Tools package. See Tools Help for a complete list of command-line parameters that you can use with Netdiag.exe. If your problem is still not solved, you can turn on the Windows Time service debug log. Because the debug log can contain very detailed information, we recommend that you contact Microsoft Product Support Services when you turn on the Windows Time service debug log. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site: http://support.microsoft.com/default.aspx?scid=fh;[LN];CNTACTMS (http://support.microsoft.com/default.aspx?scid=fh;%5Bln%5D;cntactms) Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question. NTP supports several different packet types. Typically, NTP clients and Simple N… NTP supports several different packet types. Typically, NTP clients and Simple Network Time Protocol (SNTP) clients send client mode request packets to an NTP server. The NTP server responds with a server mode packet. To configure the W32time service to send symmetric active mode packets instead of client mode packets to an NTP server, type the following command at a command prompt: w32tm /config /manualpeerlist:<server>,0×4 /syncfromflags:MANUAL Note Use the 0×8 flag to force W32time to send normal client requests instead of symmetric active mode packets. The NTP servier replies to these normal client requests as usual. Reliable time source configuration A computer that is configured to be a reliable time source is identified as the root of the Windows Time service. The root of the Windows Time service is the authoritative server for the domain and typically is configured to retrieve time from an external NTP server or hardware device. A time server can be configured as a reliable time source to optimize how time is transferred throughout the domain hierarchy. If a domain controller is configured to be a reliable time source, the Net Logon service announces that domain controller as a reliable time source when it logs on to the network. When other domain controllers look for a time source to synchronize with, they select a reliable source first, if one is available. Manually-specified synchronization With manually-specified synchronization, you can designate a single peer or list of peers that a computer obtains time from. If the computer is not a member of a domain, it must be manually configured to synchronize with a specified time source. By default, a computer that is a member of a domain is configured to synchronize from the domain hierarchy. Manually-specified synchronization is most useful for the forest root of the domain or for computers that are not joined to a domain. When you manually specify an external NTP server to synchronize with the authoritative computer for your domain, you provide reliable time. However, to provide high accuracy and security to your domain, we recommend that you configure the authoritative computer for your domain to synchronize with a hardware clock. Without a hardware time source, W32time is configured as a NTP type. You must reconfigure the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. The recommended value should be 15 minutes or even lower, depending on time source, network condition, and security requirement. This requirement also applies to any reliable time source that is configured as the forest root time source in the time sync subnet. For more information about these registry entries, see the “Windows Time service registry entries” section in this article. Note Manually-specified time sources are not authenticated unless a specific time provider is written for them, and these time sources are therefore vulnerable to attacks. Also, if a computer synchronizes with a manually-specified source instead of its authenticating domain controller, the two computers might be out of synchronization. This scenario causes Kerberos authentication to fail and could also cause other actions that require network authentication to fail, such as printing or file sharing. If only the forest root is configured to synchronize with an external source, all other computers within the forest remain synchronized with each other. This configuration makes replay attacks difficult. All available synchronization mechanisms The “all available synchronization mechanisms” option is the most valuable synchronization method for users on a network. This method enables synchronization with the domain hierarchy and may also provide an alternative time source if the domain hierarchy becomes unavailable, depending on the configuration. If the client cannot synchronize time with the domain hierarchy, the time source automatically falls back to the time source that is specified by the NtpServer setting. This method of synchronization is most likely to provide accurate time to clients. Windows Time service registry entries The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\: Collapse this tableExpand this table
Collapse this tableExpand this table
Collapse this tableExpand this table
Collapse this tableExpand this table
Collapse this tableExpand this table
|
The command vifs.php can be used to move files to and from your ESXi host. As of Update 2 of the ESXi 3.5 RCLI, this command is not supported with VirtualCenter. If you only need to copy files from your ESXi host, then you can also use your web browser to retrieve files. ESXi allows for two URLs to access files from your host.
https://<ESXi_ip/hostname>/folder – this URL can be used to browse the datastores that the ESXi has access to.
https://<ESXi_ip/hostname>/host – this URL is used to access host configuration and log files. Access to host files is controlled by the file /etc/vmware/hostd/webAccessibleConfigFiles.xml. Direct editing of this file would not be supported, but it would be possible to replace this file by customizing oem.tgz to expose more system files for editing. The below chart summarizes the host configuration / log files that are exposed by webAccessibleConfigFiles.xml and are thus downloadable via the web browser or accessible with vifs.pl
| Display Name | Host File Name | Permissions with vifs.pl |
|---|---|---|
| hostAgentConfig.xml | /etc/vmware/hostd/config.xml | GET/HEAD/PUT |
| sfcb.cfg | /etc/sfcb.cfg | GET/HEAD/PUT |
| openwsman.conf | /etc/operwsman/openwsman.conf | GET/HEAD/PUT |
| license.cfg | /etc/vmware/license.cfg | GET/HEAD/PUT |
| vmware.lic | /etc/vmware/vmware.lic | GET/HEAD/PUT |
| vmware_config | /etc/vmware/config | GET/HEAD/PUT |
| vmware_configrules | /etc/vmware/configrules | GET/HEAD/PUT |
| proxy.xml | /etc/vmware/hostd/proxy.xml | GET/HEAD/PUT |
| snmp.xml | /etc/vmware/snmp.xml | GET/HEAD/PUT |
| syslog.conf | /etc/syslog.conf | GET/HEAD/PUT |
| ssl_cert | /etc/vmware/ssl/rui.crt | GET/HEAD/PUT |
| ssl_key | /etc/vmware/ssl/rui.key | PUT |
| hosts | /etc/hosts | GET/HEAD/PUT |
| motd | /etc/motd | GET/HEAD/PUT |
| vpxa.cfg | /etc/opt/vmware/vpxa/vpxa.cfg | GET/HEAD/PUT |
| esx.conf | /etc/vmware/esx.conf | GET/HEAD/PUT |
| config.log | /var/log/config.log | GET/HEAD |
| messages | /var/log/messages | GET/HEAD |
| ipmi_sel.raw | /var/log/ipmi_sel.raw | GET/HEAD |
| ipmi_sel | /var/log/ipmi_sel | GET/HEAD |
| hostd.log | /var/log/vmware/hostd.log | GET/HEAD |
| vpxa.log | /var/log/vmware/vpxa/vpxa.log | GET/HEAD |
Note: while most systems will only have one IPMI node, a system could have up to four in which case the files ipmiX_sel.raw (/var/log/ipmi/X/sel.raw), ipmiX_sel (/var/olg/ipmi/X/sel), ipmiX_sdr_content.raw (/var/log/ipmi/X/sdr_content), ipmiX_sdr_header.raw (/var/log/ipmi/X/sdr_header.raw) and ipmiX_sensor_readings.raw (/var/log/ipmi/X/sensor_readings.raw) would be displayed where X would correspond with the node number (0 to 3). These files would have GET/HEAD permissions.
Vifs.pl can access three types of files and folders on your host.
Host – host configuration and log files as shown in the the list above. These are accessed with the path of /host/<filename>
Temp – files and folders located in the /tmp directory
Datastores – use the datastores options to access files and folders on your host’s datastores. There are two syntax options for accessing datastore files.
1) Datastore prefix = [datastore_name] relative path – for the Linux RCLI it would be ‘[datastore1] folder/filename’ and for Windows it would be “[datastore1] folder\filename”
2) URL style = /folder_path/filename=datastorename – for the Linux RCLI it would be ‘/folder/filename&dsName=datastore1′ and for Windows it would be “/folder/filename&dsName=datastore1″
Note: should the directory name include a space, then the patch should be enclosed in quotes as show in the above examples.
The vifs.pl command allows for the options shown below.
|
Option
|
Works on datastore / temp / host |
Description
|
|---|---|---|
| –copy (-c) <source> <destination> |
X / X / –
|
Copy a file from one datastore location to another. |
| –force |
X / X / –
|
Used with the copy option to overwrite the destination files |
| –dir (-D) <path> |
X / X / –
|
Lists the contents of a datastore or temp folder |
| –get (-g) <remote_file> <local_file> |
X / — / X
|
Copy a datastore or ESX(i) host file to the host running the RCLI. This operation uses HTTP GET (see accessing files via a URL above). |
| –listdc (-C) |
X / — / X
|
Lists available datacenter paths on the host |
| –listds (-S) |
X / — / X
|
List the datastore names that a host has access to. If you are using multiple datacenters, then use the –dc (-Z) argument to specify the name of the datacenter from which to list the datastore |
| –dc (-Z) <datacenter_name> |
X / — / X
|
Not used with single-host operations, this option will specify the datacenter context |
| –put (-p) <local_file> <remote_file> |
X / X / X
|
Copy a file from the RCLI host to the ESX(i) host using HTTP PUT |
| –move (-m) <source> <destination> |
X / X / –
|
Move a file from one datastore to another |
| –rm (-r) <remote_file> |
X / X / –
|
Delete a file on the ESX(i) host |
| –rmdir (-R) <remote_folder> |
X / X / –
|
Delete a folder on the ESX(i) host |
| –mkdir (-M) <remote_folder> |
X / X / –
|
Create a folder on the ESX(i) host |
Sample Session
vifs.pl –server 192.168.1.40 –username root –dir “[datastore1] SAN01″
SAN01-flat.vmdk
SAN01.vmdk
XVS-flat.vmdk
XVS.vmdk
XVS.vmsd
XVS.vmx
XVS.vmxf
vifs.pl –server 192.168.1.40 –username root –dir [datastore1]SAN01
SAN01-flat.vmdk
SAN01.vmdk
XVS-flat.vmdk
XVS.vmdk
XVS.vmsd
XVS.vmx
XVS.vmxf
vifs.pl –server 192.168.1.40 –username root –copy /vmfs/volumes/datastore1/SAN01/XVS.vmx /vmfs/volumes/datastore1/SAN01/XVS_backup.vmx
Copied file from /vmfs/volumes/datastore1/SAN01/XVS.vmx to /vmfs/volumes/datastore1/SAN01/XVS_backup.vmx successfully.
vifs.pl –server 192.168.1.40 –username root –listdc
ha-datacenter
vifs.pl –server 192.168.1.40 –username root –listds
NFS1 (1)
datastore1
vifs.pl –server 192.168.1.40 –username root –get [datastore1]SAN01/XVS.vmx c:\tmp\XVS.vmx
Downloaded file SAN01/XVS.vmx to c:\tmp\XVS.vmx successfully.
vifs.pl –server 192.168.1.40 –username root –get [datastore1]SAN01/XVS.vmx c:\tmp\XVS.vmx –protocol http
Note: you can download via HTTP if you have enabled this. This has the potential to speed up copies by 10 to 15%
vifs.pl –server 192.168.1.40 –username root –put c:\tmp\XVS.vmx “[datastore1] SAN01/XVS2.vmx”
Uploaded file c:\tmp\XVS.vmx to SAN01/XVS2.vmx successfully.
vifs.pl –server 192.168.1.40 –username root –rm “[datastore1] SAN01/XVS2.vmx”
Remove ‘SAN01/XVS2.vmx’? (y/n) : y
Deleted file [datastore1] SAN01/XVS2.vmx successfully.
The copying and moving of datastore files and folders can also be done with the VI client. Right click on the datastore and select “Browse Datastore”. You can then use the highlighted icons to manage files and folders or you can right click to get these options.
ESXi 3.5 does ship with the ability to run SSH, but this is disabled by default (and is not supported). If you just need to access the console of ESXi, then you only need to perform steps 1 – 3.
1) At the console of the ESXi host, press ALT-F1 to access the console window.
2) Enter unsupported in the console and then press Enter. You will not see the text you type in.
3) If you typed in unsupported correctly, you will see the Tech Support Mode warning and a password prompt. Enter the password for the root login.
4) You should then see the prompt of ~ #. Edit the file inetd.conf (enter the command vi /etc/inetd.conf).
5) Find the line that begins with #ssh and remove the #. Then save the file. If you’re new to using vi, then move the cursor down to #ssh line and then press the Insert key. Move the cursor over one space and then hit backspace to delete the #. Then press ESC and type in :wq to save the file and exit vi. If you make a mistake, you can press the ESC key and then type it :q! to quit vi without saving the file.
6) Once you’ve closed the vi editor, run the command /sbin/services.sh restart to restart the management services. You’ll now be able to connect to the ESXi host with a SSH client.
Tip – with some applications like WinSCP, the default encryption cipher used is AES. If you change that to Blowfish you will likely see significantly faster transfers.
Update for ESXi 3.5 Update 2 – With Update 2 the service.sh command no longer restarts the inetd process which enables SSH access. You can either restart your host or run ps | grep inetd to determine the process ID for the inetd process. The output of the command will be something like 1299 1299 busybox inetd, and the process ID is 1299. Then run kill -HUP
Adding a SSH Cert
1) Generate the public / private key pair
2) Edit /etc/passwd – add “root” to the root entry so the line will be like this
root:x:0:0:Administrator:/root:/bin/ash
3) Run mkdir -p /root/.ssh
4) Copy the public key to /root/.ssh/authorized_keys
5) Run chmod -R 700 /root
Attempt to login with your SSH client.
Then bundle the /root folder into oem.tgz. You could also do /etc/passwd and /etc/inetd.conf, but I only tested the /root folder.
Exit Tech Support Mode – Alt F2
Let’s go to practice a bit. Let’s have a NFS server in the network available. And we would like to backup virtual machines (VMs) from one of our ESX hosts directly to it, without usage of any specialized backup software.
I don’t have to forget to say that VCB is available in your ESX host. There is installed VMware-esx-backuptools package which contains almost all the mentioned commands before – vcbVmName, vcbMounter and vcbRestore. The vcbRestore utility is available only with ESX and it is used to restore a virtual machine from full backup. Additionally, the missing mountVm command is available with VCB for Windows only. Don’t forget to keep in mind that VCB commands for ESX are case-sensitive beause of service console based on Linux.
esxcfg-firewall -e nfsClient
You can check all the available services with:
esxcfg-firewall -s
To check if the nfsClient service was enabled, run this:
esxcfg-firewall -q nfsClient
If so, you will receive:
Service nfsClient is enabled.
Finally, we need a backup script whose only task is to backup available VMs. The script can be scheduled at ESX host via cron service or from the NFS backup server. It’s your choice. The script follows:
#!/bin/sh
BACKUP_SERVER="192.168.1.1"
BACKUP_DIR="/backup/vm"
MOUNT_DIR="/backup/snap"
[ -d $MOUNT_DIR ] || mkdir -p "$MOUNT_DIR" || exit 1
VM_BACKUP="`vcbVmName -s any: | grep name: | cut -d':' -f2`"
if [ ! -z "$VM_BACKUP" ]; then
mount $BACKUP_SERVER:$BACKUP_DIR $MOUNT_DIR || exit 1
for VM in $VM_BACKUP; do
vcbMounter -a name:$VM -r $MOUNT_DIR/$VM
done
umount $MOUNT_DIR
fi
exit 0
Now, simple description of the script. At the beginning, there are defined some variables – the NFS server IP address, the exported directory and the local mount point. Then, the available VMs are listed and saved in a variable. The exported directory from the NFS server is mounted and with the vcbMounter command the VMs are backuped. Finally, the directory is unmounted. If you want to use the commands without authentication credentials, you need to define them in the file /etc/vmware/backuptools.conf. Exactly, these parameters are required:
VCHOST=127.0.0.1 USERNAME=admin_user PASSWORD=admin_user_password
So, the task to backup virtual machines isn’t so sophisticated. In the next article, I’m going to restore them with vcbRestore command.
esxcfg-firewall -q smbClient
The output of command should be by default:
Service smbClient is blocked.
To reconfigure ESX firewall to allow smbclient access use the next command:
esxcfg-firewall -e smbClient
Now, you should be able to browse the server (the command asks for user’s password first):
smbclient -L 192.168.1.1 -U backup
The example command output follows (Samba server on SLES10):
Domain=[NAS] OS=[Unix] Server=[Samba 3.0.28-0.2-1625-SUSE-CODE10]
Sharename Type Comment --------- ---- ------- profiles Disk Network Profiles Service backup-smb Disk IPC$ IPC IPC Service (Samba 3.0.28-0.2-1625-SUSE-CODE10) Domain=[NAS] OS=[Unix] Server=[Samba 3.0.28-0.2-1625-SUSE-CODE10]
Now, we are ready to create a simple backup script:
#!/bin/sh
BACKUP_SERVER="192.168.1.1"
BACKUP_USER="backup"
BACKUP_PASS="backup"
SMB_SHARE="backup-smb"
MOUNT_DIR="/backup"
[ -d $MOUNT_DIR ] || mkdir -p "$MOUNT_DIR" || exit 1
VM_BACKUP="`vcbVmName -s any: | grep name: | cut -d':' -f2`"
if [ ! -z "$VM_BACKUP" ]; then
smbmount //${BACKUP_SERVER}/$SMB_SHARE $MOUNT_DIR \
-o username=${BACKUP_USER},password=$BACKUP_PASS || exit 1
for VM in $VM_BACKUP; do
vcbMounter -a name:$VM -r $MOUNT_DIR/$VM
done
umount $MOUNT_DIR
fi
exit 0
It is simple, isn’t it? The code is almost the same as for backups over NFS. We added variables defining our Samba user and his password. The mount command was exchanged with smbmount which is CLI Samba client. If you insist on using the mount command replace the line mounting the backup-smb share with line:
mount -t smbfs //${BACKUP_SERVER}/$SMB_SHARE $MOUNT_DIR \
-o username=${BACKUP_USER},password=$BACKUP_PASS || exit 1
That’s all. In such simple backup scenarios I prefer NFS usage because it is simple to set and provides higher throughput than SMB protocol. On the other hand, SMB protocol provides basic authentication mechanism (if you don’t disable it).
Solution
- Broadcom HT1000
- Intel ICH-7
- Intel ICH-9
- Intel ICH-10
- Intel Ibex Peak
|
Controller
|
Mode support
|
Support SATA hard drive
|
Support SATA Optical Drive (CD or DVD)
|
Hard drive VMFS Support
|
|
Broadcom HT 1000
|
AHCI/SATA mode only
|
Yes
|
No
|
No
|
|
Intel ICH-7
|
IDE/ATA mode only
|
No
|
Yes
|
N/A since there is no hard drive support
|
|
Intel ICH-9
|
Limited 2
|
Yes
|
Yes
|
No 1
|
|
Intel ICH-10
|
Limited 2
|
Yes
|
Yes
|
No 1
|
|
Intel Ibex Peak
|
Limited 2
|
Yes
|
Yes
|
No 1
|
[1] Even though creating VMFS while operating in AHCI/SATA mode is technically possible, VMware does not support this configuration.
[2] Both AHCI/SATA and IDE/ATA mode is supported. However, in IDE/ATA mode, ESXi Installable is not supported
- If you are using AHCI/SATA mode on SATA optical drive, the guest operating system does not have access to the optical drive. Only VMkernel and the service console have access to optical drive. This limitation is removed in ESX Server 3.5 Update 5.
- If you are using IDE/ATA mode, VMFS is not supported.ESX Server 3.5 releases prior to ESX Server 3.5 Update 5 only export IDE CD-ROM devices to the guest operating system. They do not export SCSI CD-ROM to the guest operating system. In other words, the guest operating system can attach CD-ROM devices via IDE controller only. You cannot attach CD-ROM devices via SCSI controller because ESX does not support connecting SCSI CD-ROMs or ISO images. This is true even if underlying ESX storage driver exposes SCSI interface to VMkernel. This limitation is removed in ESX Server 3.5 Update 5 with the support for SCSI CD-ROM drive in the AHCI/SATA mode.While running in AHCI/SATA mode, ESX loads its AHCI drivers which enable I/O access to a CD-ROM or hard-drive connected through a I/O Controller Hub (ICH). AHCI is a SCSI-based driver that exports SCSI interface to VMkernel. However, in releases prior to ESX Server 3.5 Update 5, the guest operating system does not have direct CD-ROM access because this is a SCSI-based CD-ROM.
While running in IDE/ATA mode, ESX loads its IDE-based drivers which enable I/O access to a CD-ROM or hard-drive connected through an I/O Controller Hub (ICH). Guest operating systems have CD-ROM access because this is an IDE-based CD-ROM. However, I/O speed to the hard drive is slower than in AHCI/SATA mode, which is why most high-end servers do not use IDE/ATA mode for hard drive use.
For hard drive usage, note that, by design, VMFS datastores cannot be created on an IDE-based interface. For an AHCI/SATA based interface, while it is technically possible to create a VMFS datastore on these SCSI-based drives, such a configuration is not supported by VMware mainly because SATA protocol does not support reserve/release. Reserve/release is needed if VMFS is used as a clustered file system in a shared disk environment.
|
Mode
|
CD-ROM access to ESX
|
Hard drive access to ESX
|
VMFS
|
Can GOS access CD-ROM
|
|
AHCI/SATA
|
Yes
|
Yes
|
No*
|
Yes#
|
|
IDE/ATA
|
Yes
|
Yes, but slower than SATA
|
No*
|
Yes
|
* This is a known limitation.
- The above image is not applicable for ESX Server 3.5 Update 5. ESX Server 3.5 Update 5 supports SCSI CD-ROM access from the guest operating system.
- ESX 3.5 automatically determines which mode to run (either IDE/ATA or AHCI/SATA) based on the BIOS setting in the machine.
-
Does the guest operating system/CD-ROM access limitation only apply to ESX 3i (embedded)? What about classic ESX 3.5?
This limitation applies to both ESX 3i (embedded) and ESX 3.5. However, this limitation is removed in ESX Server 2.5 Update 5.
-
In prior ESX Server 3.5 releases, the guest operating system was always able to have direct access to the CD-ROM. Why are you saying that the guest operating system may not have CD-ROM access anymore in ESX 3.5 Update 4? This sounds like a regression. What has changed?
In the past, the guest operating system had CD-ROM access because ESX 3.5 was using IDE/ATA interface and not AHCI/SATA interface. In ESX 3.5 Update 4, if you continue to use IDE/ATA interface, the guest operating system will continue to have CD-ROM access. This is not a regression, as no functionality has changed. What has changed recently is the introduction of AHCI/SATA support in Update 3, which now gives the server vendor the choice to configure their I/O controller to either in IDE/ATA or AHCI/SATA. If a server is configured with the ICH10 controller to use AHCI/SATA mode, for example, then the guest operating system will not have access to CD-ROM if you are using ESX Server 3.5 Update 4 or earlier releases. However, in ESX Server 3.5 Update 5, the guest operating system will have access to CD-ROM if the server is using either the IDE/ATA interface or the AHCI/SATA interface.
-
In ESX Server 3.5 Update 5, how do I add a SCSI CD-ROM or DVD drive to a virtual machine?
To add a SCSI CD-ROM or DVD drive, first edit the virtual machine settings and move the SCSI drive to scsi0:1 instead of scsi0:0. Save this setting. Now again edit the virtual machine settings and add the new SCSI CDROM type device to the VM as scsi0:0. Save this setting.”
6
VMware vSphere – Fault Tolerance
0 Comments | Posted by admin in 4.0, ESX, ESXi, Fault Tolerance, HA
VMware High Availability provides protection against physical servers failures running ESX hypervisors. If one host in HA cluster fails then failed virtual machines are restarted on another alive host from cluster. It ensures the host has enough resources to fulfill requirements of newly booted virtual machines. It is able to monitor virtual machine activity by checking its heartbeat as well and in case of its failure to restart it.
The next logical step is fault tolerant virtual environment. VMware vSphere 4 can do it . It provides zero downtime and data integrity of virtual machines in case of physical server failure.
When you configure a virtual machine to be fault tolerant a secondary duplicate machine is created on a different host. Then, any operation performed on the primary machine is recorded and replayed on its duplicate. If the primary fails the secondary takes over and continues running without interruption. However, current version is not able to monitor applications running inside virtual machines but it should be available in future.
VMware Fault Tolerance or VMware FT as it is denoted is cool and must have feature but to implement it means to meet these requirements:
- VM (virtual machine) must be in HA cluster
- esx host ssl certificates checking has to be enabled
- VM has to be stored on shared storage
- VM’s virtual disks have to be in thick format, thin is not supported already
- three VMkernel 1G ports are required, one for VMotion and two for FT
- FT doesn’t support Virtual SMP, only single processor VMs are supported!
- physical hosts have to support hardware assisted virtualisation, no problem with recent servers
The most of requirements are common ones but points 4 and 6, for older servers 7 as well, are considerlable limitations. It’s not so simple to implement VMware FT but I hope it will get better in next releases.
Finally, vSphere documentation is available at vmware.com.
