On Sun, Oct 08, 2006 at 05:15:31AM -0700, Mathew Brown wrote: > Hi, > Actually, just a small point of clarification. Guest OSes can know if > they're running in a hypervisor in hardware virtualization. If you're > using AMD-V, there's an instruction called VMMCALL that allows the > guest OS to check to see if it's running under a hypervisor or not. > On Intel, the equivalent instruction is VMCALL. This is useful > because if it finds that it is running under a hypervisor, it can do > things such as ask for more memory if it's running out of memory or > ask for more disk space. Here's an article about if: > http://developer.amd.com/articles.aspx?id=15&num=3 You can also > search google for VMMCALL or VMCALL :) > > PS. Of course, the guest OS would have to have the ability to do this > check. I'm not sure how complicated it would be. Probably a patch to > the kernel or something. Once you start patching the guest kernel to have knowledge of & talk to the hypervisor, haven't you now just become para-virtualized instead of fully-virtualized:-) Albeit, hardware assisted paravirtulization in the example you illustrate. It will be interesting to see in the future if AMD-V / Intel-VT allow some more interesting things to be done with paravirt guests, but currently they're only relevant for enabling Xen to do fully-virt. The term fully-virt is commonly held to mean a completely unmodified OS that has no knowledge of the hypervisor. Fully-virt can be hardware enabled, for example, Xen HVM support with Intel-VT or AMD-V; or it can be trap-and-emulate such as VMWare. In either method though the guest kernel will have issues doing accurate scheduling. Consider you have 2 guest's running on a 1 CPU box. Guest A is currently active & decides to schedule process 'cron' for a 30 ms timeslice. 10 ms later though, the hypervisor decides its time to let Guest B run for say 10 ms, before letting Guest A run again. So in this case Guest A thinks it gave cron 30 ms of runtime (and accounted for this), but in fact cron only got 20 ms of time on the CPU. Unless you modify the guest OS to talk with the hypervisor to find out when it has been allowed to run by the HV, its process accounting will always be inaccurate in this way. This is one very compelling reason for para-virt over fully-virt. >i > > On Sat, Oct 07, 2006 at 11:12:00PM +0200, Aryanto Rachmad wrote: > > > ----- Original Message ----- > > > From: "Daniel P. Berrange" <berrange redhat com> > > > To: "Aryanto Rachmad" <aryanto chello at> > > > Cc: <fedora-xen redhat com> > > > Sent: Saturday, October 07, 2006 10:43 PM > > > Subject: Re: What are the minimal required FC6 packages for Dom0? > > > > > > > > > > > > > > Fully-virt just lets you run unmodified operating systems (notably Windows, > > > > or older versions of Linux for which there is no Xen kernel available). > > > > If you only care about running modern Xen enabled Linux kernels then > > > > you have on need for fully-virt. As a general rule, if there is a paravirt > > > > version of your desired OS available, using that will always be preferrable > > > > to fullyvirt. The network & disk I/O is much faster in paravirt, and since > > > > the kernel is informed when the hypervisor re-schedules it, it can do much > > > > more accurate process accounting in the guest. It is basically impossible > > > > to do accurate process scheduling in fully-virt, since the guest kernel > > > > has no knowledge of the fact that its running under a hypervisor. > > > > > > > > > > Thanks a lot Dan, > > > > > > I am actually planning to use Windows XP on one of the guests. So in this case I can not > > > do that, cann't I? But on the other hand, I prefer para-virtualised as it has more > > > advantages as you explained. > > > > Yeah, for Windows XP you'll need an Intel-VT or AMD-V capable CPU. > > > > Regards, > > Dan. > > -- > > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| > > |=- Perl modules: http://search.cpan.org/~danberr/ -=| > > |=- Projects: http://freshmeat.net/~danielpb/ -=| > > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| > -- > Mathew Brown > mathewbrown@xxxxxxxxxxx > > -- > http://www.fastmail.fm - Or how I learned to stop worrying and > love email again > > -- > Fedora-xen mailing list > Fedora-xen@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-xen -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
