9:23 a.m.
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: [Fedora-xen] 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(a)fastmail.fm
--
http://www.fastmail.fm - Or how I learned to stop worrying and
love email again
--
Fedora-xen mailing list
Fedora-xen(a)redhat.com
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 -=|