Re: vmWare, virtualPC, dedect , ... IN/OUT
From: Chuck Chopp (ChuckChopp_at_rtfmcsi.com)
Date: 07/27/04
- Next message: Alexander Grigoriev: "Re: problem with COMTIMEOUTS"
- Previous message: Tim Roberts: "Re: WINAPI and CALLBACK"
- In reply to: Ivan Brugiolo [MSFT]: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Next in thread: Mario Semo: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Reply: Mario Semo: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 27 Jul 2004 19:38:21 -0400
Ivan Brugiolo [MSFT] wrote:
> Again, only the original poster can aswer to this.
> But, you hit the point: you can buy one licence, activate that licence
> on a virtual-machine, and clone the virtual machine.
> Decoupling phisical devices (the small soap-box for the parallel
> port used in the old good days is one example) from executing environment
> is both a powerful technique and a new field of research for
> licence writers and lawyers in general.
> The business practices of the next few years will tell us what will
> be the generally understood way of doing things inside a virtualized world.
Actually, cloning of a virtual machine shouldn't be any different than using
Ghost or DriveImage for cloning hard drive images for physical workstations.
As far as WinXP/Win2K3 product activation goes, changing the virtual hard
drive size, # of virtual network adapters or their MAC addresses [new one on
each virtual machine], changing the amount of memory assigned to the VM or
even changing the actual CPU [e.g. different host systems with different
CPUs], then the product will need to be re-activated due to the hardware
changes. This is the same as what happens when you change the physical
hardware on a physical computer system.
Although it is possible to clone a single VM such that the copy of it even
has the same MAC address on its NIC and the copy of Windows on it keeps the
same system SID, the usefulness of the clone would be very low except as a
standby system. Concurrent usage of both virtual machines would be limited
to non-networked situations if they have duplicate MAC addresses.
Those back-door I/O ports in VMware and VirtualPC exist to allow the client
tools for the guest O.S. to communicate back into the host portion of the
virtual machine software to provide additional functionality & features that
augment the whole virtual machine experience.
Even devices like USB dongles used for license enforcement aren't shared
across multiple virtual machines. When the dongle get plugged into a USB
port, the device either gets controlled by the host's O.S. itself or one
single VM is allowed to "see" the dongle as a USB device and thus make use
of it. The same goes for COM ports, named pipes, FireWire devices, etc....
I'll just wait to see what the O.P. has to say about why it is important to
detect if a program is running on a virtual machine.
-- Chuck Chopp ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com RTFM Consulting Services Inc. 864 801 2795 voice & voicemail 103 Autumn Hill Road 864 801 2774 fax Greer, SC 29651 Do not send me unsolicited commercial email.
- Next message: Alexander Grigoriev: "Re: problem with COMTIMEOUTS"
- Previous message: Tim Roberts: "Re: WINAPI and CALLBACK"
- In reply to: Ivan Brugiolo [MSFT]: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Next in thread: Mario Semo: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Reply: Mario Semo: "Re: vmWare, virtualPC, dedect , ... IN/OUT"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|