It's essentially the same as a Windows terminal server or a Citrix, where the users have a connection to a socket inside of the operating system. Except, instead of getting a slice of the pie, they get the whole pie to play in.

We have done this in a few places. I think it is best to make sure it starts automatically if you want them to only use the VM of course. If you use VMware View Client I know there is a way to set it up so it starts automatically with the server info already there, they just have to log in.

Its possible once you convert it to a virtual machine. I guess you might have to change the SID of physical machine and the name so it wont clash with the Virtual one.Maybe rejoining it to the domain also. I am not sure if there is a easier way than using RDP for the user to connect to the Virtual machine.

The virtual machine can be thought of as a distinct Server or Workstation on the network. I'm not sure I understand your question correctly. You don't make physical machines into virtual ones per se, it is still a physical machine. A physical machine can be just that, a physical machine or a host for virtual machines. What Stiegelis says is correct, that you can virtualize a workstation, rename it so you have no conflicts, and basically have two identical workstations with one physical and one virtual. However, I don't see the point in doing something like this. Usually what is done when people talk about P2V, they are converting a physical machine to virtual (for a whole host of benefits and reasons) and the physical machine is then decommissioned or repurposed.

When you say how do they "see" it, basically you access virtual machines remotely - access services on them like you do with Servers, Remote Desktop, the VM Console, or any other remote thechnology. VMs are just other resources on your network like Servers and remote workstations - you use them the same way, they can just be consolidated onto physical hardware with several VMs hosted off of it. Or as you mentioned your home environment - the VM running on your physical machine is, with respect to the network, a second independent machine and is treated as such (from the network perspective, it doesn't know it is sharing your hardware, it is a separate device).

Hope this helps. So much can be done with virtualization, I just think you are looking at it wrong. Once you start seeing how it can be used, you wonder how you ever got by with physical machines all over the place.

Its possible once you convert it to a virtual machine. I guess you might have to change the SID of physical machine and the name so it wont clash with the Virtual one.Maybe rejoining it to the domain also. I am not sure if there is a easier way than using RDP for the user to connect to the Virtual machine.

Sorry, meant to add this as a respones to "me again".

You will have to rename it on the Domain. Disjoin and rejoin is not necessary. Changing the SID is not needed. Check Microsoft Technet where all the Sysinternals tools live now - NewSID was removed as they learned it was not necessary. They have a whole explanation of why it is not necessary if you're interrested. I used to use NewSID all the time when I would clone physical machines until I saw this.

Jordan : Atm am not using anything myself,its just thoughts and knowledge that might come in handy.If i cant get this piece straight i cant move on to more complicated stuff.Also,i like to test things up :)

But,yeah what you said.Even with a thin client i dont know excactly what is going on to "connect" to the VM machine.

Lets say i want to P2V and then forget about the physical windows enviroment but keep the hardware to login to the new VM (which essentially be the same,same desktop,same icons etc.)

I mean,yeah throw away the physical but how will the user then sit in his office and work on the virtual one?

This is where i get confused.

There is no difference in how a VM guest functions and how a physical install works (broad generalization that has a host of caveats, but for the sake of this discussion it is correct). If you have a physical server that you RDP into you can RDP into a properly configured guest just as easily, or http, or telnet, or VNC, or file sharing, etc. The VM host just provides the "hardware" for the guest so that it can function just as if it were running on physical hardware.

Then you get into public and private virtual switching, but that is another discussion entirely. What I said above is true if you assume that you provide the VM a network connection to your physical network through your host's physical NIC(s).

Usually, our school districts will start with just buying the licensing required for the VM's and go from there. It is a cheaper route than buying thin clients and it is a good starting place. We have no issues implementing it this way but it is kind of a pain management wise.

My advice: I would install a linux OS on the existing box and then use whichever platform you want to connect to your VM.

so whatever the procedure the end user will have to work in his virtual windows through some sort of remote software or protocol?

If you're wanting them to be able to have console access rather than RDP or the like then you will need to install management software of some description. It varies based upon the virtualization platform that you are using. With HyperV you have HyperV Manager. I'm not sure about the tool in VMware or Xen, but I know they're there.

I get several users in the company,lets assume i want one of them to stay where he is with the same excact computer(physical)

running windows xp and make a virtual..image of that computer if am saying it correctly.So,then i format his computer and i want him (somehow...) to use his hardware to work in the virtual machine (which am guessing has to be in a server ).

I suppose he has to configure his NIC and...well all the above imagination dont know if is possible the way i think of it.

so whatever the procedure the end user will have to work in his virtual windows through some sort of remote software or protocol?

Yes, the virtual machine is just a machine on your network. You still need to access the VM from something (a physical box, tablet, vSphere Console, etc.). Think of VMs as always remote - it is like connecting to a Server or workstation in the next room. The only way to use the workstation in the next room is via some remote console technology (RDP, whatever). Same with VMs. Also because VMs are essentially just Servers and workstations just like their physical analogs, the same remote restrictions apply - Windows Pro OSs allow only one connection be it the console or RDP. Servers allow 2 Administrative RDP connections unless you are running Terminal/MultiPoint Servers. Other Servers function as if they were physical (from a network perspective). My Exchange Server does all the things that a physical box can do (your Outlook clients don't know it's a VM, they just connect to Exchange and do mail stuff. The beauty of the Exchange being a VM... If drive space is low, it add more drives or increase a drive size ON THE FLY. with vSphere and shared storage, I can move it (or portions of it) to other Hosts and/or storage all while it is LIVE. If it needs more horse power, I can allocate more CPUs or memory which are picked up after a quick reboot (of course, you need the horsepower available on your Host to do this). I can add a additional NIC to a Server while it is running. The list goes on.

I get several users in the company,lets assume i want one of them to stay where he is with the same excact computer(physical)

running windows xp and make a virtual..image of that computer if am saying it correctly.So,then i format his computer and i want him (somehow...) to use his hardware to work in the virtual machine (which am guessing has to be in a server ).

I suppose he has to configure his NIC and...well all the above imagination dont know if is possible the way i think of it.

Do i make better sense now utleast? :-S

I don't see the sense in this. Not sure why you want them to work in VMs. A typical scenario is like this. We have developers that need to test stuff. They use a physical machine for their development work. They use VMs for testing - this gives us the ability to have snapshotted (allows you to turn back the clock like restoring a previous image or something like Deep Freeze) - We can have an assortment of Win XP, 7, 8 both 32 and 64-bit that can be fired up at any time. The VMs can be run from their own workstations using VMPlayer or something like that or, as we do, they can all live on a ESXi Host Server. In both cases, they have to connect to the remote test machines - we use RDP but there are many other ways. They still have to run the RDP session from some physical device - even when their workstation is both the client and Host.

Matt : Some machines here have complicated and old software and external hardware attached.If something is changed in the configuration or destroyed it will be a big pain in the butt to get them back together and working.

Maybe am thinking of a disaster scenario and having a vm image of them might save me.

Some machines here have complicated and old software and external hardware attached.

Then it becomes even more complicated for the hardware part, since your VM is no longer actually to the hardware in question (since it's sitting on a server somewhere). It can get tricky, impossible in many cases, for your remote VM to access local hardware resources.

Essentially you're thinking about what's called VDI, Virtual Desktop Infrastructure. VDI usually isn't an inexpensive solution, most times it's well outside an SMB's budget (there are exceptions of course). If you think about it, you need to a beefy server to run your VMs, and have appropriate licensing for them. Then you need a bunch of workstations or thin clients, and licensing for them as well depending on what you're using. VDI as a DR solution sounds a bit overkill; you can likely get a centralized backup and recovery solution for ALL your workstations for much cheaper.

(VDI is still really cool though. I wish I had the opportunity to implement it where I work.)