Pssession- computername vs vmname for Enter-pssession
-
You didn't go too fast. I ran the get-pssession and there are none.
-
Exit-PSSession just disconnects you from the remote session, it is still running on the remote machine.
This is the persistence, and allows you to reconnect when necessary.Try this hitting enter after each line
New-PSSession -VMName virt3datactr (enter creds when prompted) Get-PSsession (Note the name of the session) Enter-PSSession -Name xxx (replace xxx with the name of the session) Exit-PSSession (the session is still running on the remote machine) Get-PSSession (verify the session is still there)
If you leave that session running, its consuming resources on the remote machine and could be a potential security risk. Its really easy to forget you exit the session and think its done. Temporary sessions are ended when you Exit-PSSession Because its persistent, Exit-PSSession doesn't end the session, just disconnects from the session. Therefore, you must first exit the session, and then remove the session.
-
That's the big difference between temporary sessions and PSSessions.
Exit-PSsession terminates a temporary session
Exit-PSSession disconnects a PSSession
Remove-PSSession terminates a PSSession -
ok, got it
-
Great!!
I hope this helps with your understanding of PSSessions.
If you have other questions, let me know 😎
-
@Mike-Rodrick it does immensely. just one last one. what's different between using vmname and computername?
-
-VMName
is used when you are logged on to the Hyper-V host and want to connect to a VM that is running on that host.-ComputerName
is used when you are not on the Hyper-V host and want to connect to the same VM. You treat the VM like any other computer on the network.The VMName (the name listed in the Hyper-V console) is only known to the Hyper-V host. To connect from anywhere else, you need to know the ComputerName.
If you right-click on virt3datactr in the Hyper-V console, you can rename the VM. But this does not change the hostname inside Windows on virt3datactr.
Try this:
Right-click on virt3datactr and rename it to something else, like demo3vm.
Now log on to that vm, open PowerShell and typehostname
It will still be virt3datactr. Only Hyper-V knows the name demo3vm. The network still knows the VM as virt3datactr.You can right-click again and change it back
-
Not following. If I am using a hyper-v host then only the vmname will work and if I'm connecting to another host then computername would be the cmdlet to use? the host name of my vm is the same as the hyper v name
-
What is the name of your laptop?
-
If you are logged on to the Hyper-V host (your laptop in this case), and want to connect to a VM (like virt3datactr), you need to use the -VMName parameter.
But if I wanted to connect to virt3datactr from my laptop, I would need to use the -ComputerName parameter.
-
desktop-kcg0j0v
-
The error I was getting using computername from my laptop was what prompted my question. virt3datactr is the computername I assigned it in system preferences
-
The Hyper-V server here at ITProTV runs several VMs. I rarely log on to the Hyper-V server. I am usually working from my laptop. This is pretty normal for an enterprise environment.
When I create a PSSession to one of the VMs running on our Hyper-V server, I use the -ComputerName parameter. This is the name of the VM that the network sees.
If on that rare occasion I first remote into our Hyper-V server, and then from there want to create a PSSession to one of the VMs, I use the -VMName parameter, because I am on the Hyper-V host itself.
Make sure you are understanding that the VMName and the ComputerName are usually the same, but don' t have to be.
-
Yep, the name you set in system preferences is not the same as the name that is listed in the Hyper-V console. They might be set to the same name, but if you change one, it doesn't change the other.
The name in system preferences is the computername.
The name in the Hyper-V console is the VMName.
You could right-click on the VM in the Hyper-V console and rename it Blue123
Now the VMName is Blue123, but the computername in system preferences is still virt3datactr -
@Mike-Rodrick I don't think I am understanding that.
-
I guess I'm thonking if the hyper-v server is aware of the vm's why wouldn't either cmdlet work?
-
When you first create a VM, there is no operating system. You still have to call the VM something. Lets say you call it demoVM. This is the VM name. Only the Hyper-V server that you created the VM on knows this name.
Now you install Windows in the VM. As part of the installation, Windows generates a random name, something like desktop-egjdsd. This is the computer name. This is what the network sees. This is the name that gets registered with DNS so other machines on the network can find it. Most people will change this name to something more meaningful. Like myLaptop, or client01. This is the name you set in system preferences.
But this doesn't change the VM name. It is still listed in the Hyper-V console as demoVM. You can change them to match, but they are independent, and changing one doesn't change the other.
Now when you want to create a PSSession, the name you use to identify the VM you want to connect to depends on where you are connecting from.
If you are connecting to the VM from the Hyper-V host that the VM is running on, you must use the -VMName parameter.
If you are connecting to the VM from anywhere else, you must use the -ComputerName parameter.
-
@John-DeWilde said in Pssession- computername vs vmname for Enter-pssession:
I guess I'm thonking if the hyper-v server is aware of the vm's why wouldn't either cmdlet work?
That's just the way it was designed. There is an inherit trust between the Hyper-V host and the VMs on that host. When you use the -VMName parameter, the VM does not need to be listed in your TrustedHosts. The Hyper-V server can connect to the VMs that are running on it anyways. This makes it easier to manage the VMs.
-
@Mike-Rodrick said in Pssession- computername vs vmname for Enter-pssession:
When you first create a VM, there is no operating system. You still have to call the VM something. Lets say you call it demoVM. This is the VM name. Only the Hyper-V server that you created the VM on knows this name.
Now you install Windows in the VM. As part of the installation, Windows generates a random name, something like desktop-egjdsd. This is the computer name. This is what the network sees. This is the name that gets registered with DNS so other machines on the network can find it. Most people will change this name to something more meaningful. Like myLaptop, or client01. This is the name you set in system preferences.
But this doesn't change the VM name. It is still listed in the Hyper-V console as demoVM. You can change them to match, but they are independent, and changing one doesn't change the other.
Now when you want to create a PSSession, the name you use to identify the VM you want to connect to depends on where you are connecting from.
If you are connecting to the VM from the Hyper-V host that the VM is running on, you must use the -VMName parameter.
If you are connecting to the VM from anywhere else, you must use the -ComputerName parameter.
I still don't understand that. If the hyper-v host can see it wouldn't the dns server also see it? It would have to if you can connect to it by name using computername.
-
Nope. The VMName is not a DNS name. Think of it more like a folder name. Remember, in the end, a VM is a collection of files. The VM name in the Hyper-V console can be descriptive, and helps manage the VMs.
For example, I might have a VM named svr01. It belongs to the domain itpro.tv. The hostname for this machine is svr01. The FQDN for this machine is svr01.itpro.tv. The FQDN is what is registered with DNS. This is the name that other machines on the network see.
The name of the VM in the Hyper-V console is completely separate. It has nothing to do with the hostname of the server or the FQDN. It isn't registered anywhere. It is only used in the Hyper-V console to name the VM. You could name it the same as the hostname, SVR01. But this name doesn't tell you much about the VM. Lets say another admin opened the Hyper-V console. They see the VM named svr01. They wouldn't know what the OS was, what roles were installed, etc. They would have to start the machine and log in to find out. Now, if we named the VM something like WS16-DB-itprotv, we could tell from the name that the vm was running Windows Server 2016, was a database server, in the domain ITProTV.
When you only have a couple of VMs, this might not seem all that important. You know what your machines are and do. But in an enterprise environment, you might have 100's or 1000's of VMs to manage. There might be several administrators, and many machines that you didn't create. Having a good VM naming convention becomes extremely important.
I know in my shows I use simple names like laptop01, but in a production environment, this wouldn't work for long.
If you want some examples, check out this blog. He has a really well thought out naming convention.