[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] Virtualization Technique
> -----Original Message----- > From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx > [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of MaTT > Sent: 01 September 2006 10:40 > To: xen-users@xxxxxxxxxxxxxxxxxxx > Subject: [Xen-users] Virtualization Technique > > Hi all!.. > > Half of the company has Vmware (about 50 physical servers) > and the other > half is considering going to Xen, but we are confuse about > the concepts > of the two solutions. > > What is the main difference in the virtualization technique > of Xen using > VT enabled hardware and VMWare with and w/o VT? > If Xen+VT is full virtualization, what are the differences > between the > full virtualization of vmware?? Vmware uses something called "Binary translation" to support the same ideas as the hardware virtualization technologies. This means that priviliged code is scanned for special instructions, and the special instructions are replaced with a "trap" (intercept) code to get into the VMM (Hypervisor). Hardware virtuailization technologies doesn't need this, as there is functionality in the processor to figure out when any special instruction needs to be "trapped" (intercepted). Both solutions are using similar technology to emulate hardware (intercept the write operations either directly through IO-mapping intercept setup or through memory mapped page-table access restrictions), and then pretend to perform the instruction through software that changes the state of the emulated hardware based on the operation intercepted. There isn't MUCH difference between these two technologies, except it's MUCH easier to write the code to handle the HW virtualization - but there's still plenty of difficult-to-write code to handle the memory mapping (OS's in general expect that memory starts around address zero and grows up, but in a virtual machine, there may will be more than a single OS's running on the same machine, so the memory start address has to be "faked" to make it look like it's at zero for the OS, but actually be located elsewhere from the machines standpoint). And IO devices need to be emulated in some way or another (at least for any device that is shared between multiple guests). I'm not sure if this is reducing your confusion... But essentially what I'm sayins is that there's not a WHOLE LOT of difference... Performance may vary a little bit, with extremely bad cases existing for both technologies. One additional point: Xen is also supporting para-virtualization for Linux, which is a much better approach in many ways - it allows optimization of the work within the hypervisor on the guests behalf - say for instance a guest is performing 1000 writes to the page-table to map a 4MB block of memory. Since the hardware virtualization technology doesn't actually know what is happening, it has to intercept each of these writes individually, causing 1000 intercepts. The para-virtualization technology will modify the source-code to call the hypervisor for the write to page-tables, and it can easily add an extra parameter to indicate that multiple writes are needed, so it reduces the number of transitions between the hypervisor and the OS. Unfortunately, the para-virtualization technology also requires that the source-code is available to make changes to the source code and recompile it. That's why it's not available for Windows and other OS's that aren't "open source". -- Mats > > Thanks a lot!. > > Cheers > MRB > > _______________________________________________ > Xen-users mailing list > Xen-users@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-users > > > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |