Log messages are sent only to the console port by default, but can be redirected to a syslog server.
Switch(config)#logging host 172.16.0.19
Switch(config)#service timestamps log datetime msec
Remember to have NTP configured before setting the logging. The service timestamps log datetime msec timestamps the logs, but of course this is no good if NTP hasn’t been set and the clock isn’t synchronized across the infrastructure.
The console port is considered the primary terminal line and should be protected by a password.
Switch(config)#line console 0
Switch(config-line)#password console
Switch(config-line)#login
Executing the login command makes sure the console port will prompt you for authentication. You cannot use the login command without setting a password first or that line simply won’t be usable.
You can set a password on all console ports starting from line 0 – 16. Upon setting this password a prompt will appear at first connection.
Switch(config)#Enable secret edCkdso!kdl
Switch(config)#line console 0
Switch(config-line)#logging synchronous
How to change or disable the console’s default timeout value from 10mins
Switch(config)#line console
Switch(config-line)#exec-timeout 0 0
The exec-timeout value is determined in seconds.
Telnet is referred to as the vty line in Cisco IOS.
First you have to see how many lines you have available. Routers usually have considerably more than switches, and then set the password for all lines possible.
Switch(config)#line vty 0 ?
<1-15> Last Line number
<cr>
Switch(config)#line vty 0 15
Switch(config-line)#password telnet
Switch(config-line)#login
Remember to always set the Telnet password in a production environment, but use a unique one as Telnet is not an encrypted line!
First check how many lines you have and then set the password. For this I’ll showcase the login command functionality.
Router(config)#line aux ?
<0-0> First Line number
Router(config)#line aux 0
Router(config-line)#login
% Login disabled on line 0, until ‘password’ is set
Router(config-line)#password aux
Router(config-line)#login
A hostname and a domain name are needed for the encryption keys to be generated.
Switch(config)#hostname vlabdkcphsw001
vlabdkcphsw001(config)#ip domain-name itvlab.com
vlabdkcphsw001(config)#username mkbn password ssh
The name for the keys will be: vlabdkcphsw001.itvlab.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes.
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]
Vlabdkcphsw001(config)#
*mar 1 1:22:45.821: %SSH-5-ENABLED: SSH 1.99 has been enabled
vlabdkcphsw001(config)#ip ssh version 2
vlabdkcphsw001(config)#line vty 0 15
vlabdkcphsw001(config-line)#transport input ?
all All protocols (NOT RECOMMENDED!)
none No protocols
ssh TCP/IP SSH protocol
telnet TCP/IP Telnet protocol
To allow SSH and Telnet at the same time type the following
vlabdkcphsw001(config-line)#transport input ssh telnet
Every password but the secret password are visible from the sh running-config command by default. The way the encryption of the passwords work in the Cisco IOS is a little weird I think. You can use the service password-encryption to encrypt the passwords and then turn it off and they will still be encrypted.
vlabdkcphsw001(config)#service password-encryption
You can leave the service encryption ON, but this would take up processes. Use the show running-config command to first show that they have been encrypted.
vlabdkcphsw001#sh running-config
After you have verified the password encryption then you can turn off the encryption service.
vlabdkcphsw001(config)#no service password-encryption
If you execute the service encryption before setting the passwords then you don’t have to use the show running-config command. So in summary you cannot use the commands service password-encryption and no service password-encryption consecutively without the show running-config in between or your passwords won’t be encrypted!
If you enter an IP address in privileged mode the switch or router will automatically assume you want to telnet by default. And if you type a name it will automatically try to resolve it through DNS.
So have you ever seen this?
Switch#mikkel
Translating “mikkel”…domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address
This is because DNS is turned on by default, and you are forced to wait the timeout. To turn it off use the following command:
Switch(config)#no ip domain-lookup
Turning on DRS (Distributed Resource Scheduler) in a new Cluster will add an additional option to choose from.
Automation Level has three options:
The DRS Cluster will suggest relocation of VMs but not execute them.
DRS will locate a newly created VM based on work load, and will also do this at VM power ON, but not after. So the only automation here is when a VM is first created or powered ON. Afterwards it just acts like the manual setting.
Fully automated makes the DRS move VMs around at all times, and an additional option comes with this setting which is;
Conservative is the result of a partially imbalanced cluster, and an aggressive is the result of trying to come as close to a balanced cluster as possible. Moving VMs around requires resources too, so a slightly conservative threshold might be recommend although best practice is to leave it at default.
Distributed Power Management is something that is not initially visible when first creating a cluster.
To enable this setting right-click your cluster -> Settings -> vSphere DRS and press Edit.
DPM works in conjunction with DRS to balance the load on as little resources as possible. DPM uses WOL, IPMI or iLO to wake up the host when its resources are needed. Be careful with this as in some cases hosts might shutdown and startup all the time, or a host might just not wake up when it is needed.
vSphere HA comes with the option Enable admission control, and you can set this setting if you want vSphere to prevent you from powering ON too many virtual machines that would eventually violate your cluster resources. So if you have two hosts and each of them could power 10 VMs, then you would not be able to power on more than 10 VMs because the cluster is going to reserve the other host for failover capability.
In the event that you do not enable admission control and over subscribe your resources then vSphere will still try to power up as many VMs as possible when you have a host failure, but there is no guarantee. You can use VM restart priority to boot up critical VMs first;
You have to decide whether high availability is more important than running as many VMs as possible when choosing admission control.
You can set the policy on admission control based on how many hosts your cluster can tolerate, or how big of a percentage you want to reserve for failover.
If you have a two node setup and set the Host failures cluster tolerates to 1 then that would be the same as reserving 50% of CPU and memory capacity for that particular setup.
The VM Monitoring Status comes with three options:
VM monitoring only provides vSphere the ability to monitor VMware Tools and restart the VM on another host if VMware Tools becomes unavailable.
If you set it to also monitor application you must set this in conjunction with a vendor. So this is vendor specific and will not work right out of the box.
Now the last setting is EVC.
EVC mode is for making hosts of the same CPU brand (Intel and AMD) compatible between models/generations so you can vMotion. Sometimes you may want to add additional hosts to an existing cluster but the model has gone out of production, and you can only get a newer model with a CPU with lots of new features. You would then turn on EVC and downgrade the cluster to the “worst” CPU to make them compatible and mask out all those new CPU features in the new model.
I usually think of Microsoft’s Domain and Forest Functional level where you downgrade the level to the lowest version of a domain controller you have. So if you have a 2003 and 2008 domain controller you would downgrade the functional level to 2003 in that forest.
If you edit vSphere HA you will see some additional settings not visible when set on a newly created cluster.
I touched base on the VM restart priority earlier, and this can be overwritten. The next one is the Host isolation response. So what would you like to do in the event that a host would become isolated and unable to actively migrate VMs while powered ON?
What is a Host isolation response?
Host isolation is when the management network of a host becomes unavailable. This can happen for many reasons, but this means you cannot move VMs around while they are powered ON. They will still run because they have access to the storage network as seen here;
To address this issue VMware introduced Datastore Heartbeating.
This will help prevent the status of a host isolation – a second layer defense.
NFS is not optimized for virtual machines just like VMFS is, but is still widely used by admins. It is the storage solution with the worst performance among iSCSI and FC. An NFS datastore has an unlimited size as opposed to VMFS which can hold a maximum of 2TB in vSphere 5.1 and 64TB in 5.5.
NFS Properties:
I have used my Domain Controller as an NFS location. NFS is file based and not block based storage.
NFS datastore created and mounted.
This mode allows the virtual adapter of a VM to observe traffic in the virtual switch, so any traffic coming from and to another VM can be observed. By default this is set to reject since that would pose a security risk, but there are situations where this is needed – for example by an IDS system (intrusion detection system) that needs to observe the traffic to inspect packages. Can be set at both the switch and port group.
MAC address changes are concerned with blocking traffic to a VM (incoming) if its initial and effective MAC address do not match.
Forged Transmits are concerned with blocking traffic from a VM (outgoing) if its initial and effective MAC address do not match.
So if both forged transmits and MAC address changes are set to reject then no traffic will be allowed to and from the VM as long as its two MAC addresses do not match. If set to accept then no problem. MAC address can change when moved to another location. VMware recommends to set both to reject for the highest level of security possible. Although if a feature such as Microsoft Network Load Balancing (NLB) in a cluster set in unicast mode is needed the set both to accept. The default settings of a new standard virtual switch has both of these set to accept.
If you have some software you would like to install on a virtual machine, and one that does not have a network connection. You can then upload software to a VM through a datastore, but this can only be done if it has been converted to the ISO format.
All applications will then be converted into a single image.
This part makes up the end of my first post on this subject found here
Next up is migrating the iSCSI initiators. This can be done without downtime if I have spare NICs to work with. If not then I will have to disconnect the storage to get the NICs off the iSCSI adapters, and this will cause downtime.
I have spare NICs to work with so I will migrate the iSCSI storage without downtime.
So remember that my storage network has two NICs utilized to enable failover capability. For this reason I can safely remove one NIC.
So the essential part of “migrating” the iSCSI connections from a standard switch to a distributed switch is to make sure other vmkernel port bindings are available to the network port binding on the iSCSI network adapter. So it isn’t really a migration per say but rather an exchange of vmkernels and physical network adapters.
I created a vSphere network based on standard switches. I put everything in the network including management, storage, VM network, vMotion and I made everything possible to failover to a second NIC to come as close to a production setup as possible.
I played around with the design and configuration of the migration into the vDS for a few days. At a CBT nugget video Greg Shields demonstrates how he leaves one NIC to remain out of two in a redundant management standard switch when he migrates the vSS into vDS. The purpose of this was to keep a backup. However, from my own investigation it is not necessary to leave anything behind when migrating for several reasons.
Before this realization I used Greg’s method and tried to leave one NIC to remain in the standard switch. This failed at first because I migrated the standby NIC, and left the active NIC hanging with no vmkernel in the switch (and because I forgot to tag the standby nic as a management adapter in the DCUI). Upon rolling back (vSphere does this automatically) vSphere set every single NIC in my environment to standby and none of my hosts could connect to vCenter (bug maybe?).
So, for the networking designs I have done so far I have always separated everything into each its own switch, and as thus haven’t felt the need to utilize VLAN tagging inside the virtual standard switches, but only on the back-end switches. At first I migrated every single standard switch into a single vDS and utilized VLAN tagging in the vDS to separate the traffic, but this failed seemingly due to not having the back-end networking prepared at my hands.
So for this demonstration I will make an exact replica of my standard switch design, and then migrate everything into the distributed switches.
Because of the web client’s lack of option to show the complete network I used the C# client for that.
Note: The number of uplinks you specify should be the maximum number of uplinks one single ESXi host can contribute with to a single vDS. Think of uplinks as the slots available for an ESXi’s NICs to plug in to. Each of my two ESXi hosts have 8 physical network interface cards installed, so I should set 8 if I wish to migrate all port groups into the same switch. However, since I will create a distributed switch per port group I only need to specify to. The number of uplinks can also be changed after deployment.
Next up is migrating the iSCSI connections.
IT vlab 