# Stupid KVM questions.  Solved

## 1clue

Hi,

I have what is almost certainly a stupid question but I can't really get it straight in my head.

If I'm running KVM on a different platform (say CentOS) and then create a Gentoo VM, can I get access to the real hardware type of the bare metal?

I know on a normal virtualization scheme the answer would be no, but somewhere I read that KVM is different and that I can see what's really under there.  Frankly I don't see how that can be, but if it's true then I should be able to compile a kernel for the hardware of the host, and could potentially dual-boot into the VM directly on the bare metal.

Or am I off in the world of Oz?

Thanks.Last edited by 1clue on Tue Jul 23, 2013 2:11 pm; edited 1 time in total

----------

## VinzC

Hi 1clue.

 *1clue wrote:*   

> can I get access to the real hardware type of the bare metal? 

 

It all depends on what you mean by "access". Fact is KVM features some pass-through functionalities that allow you to dedicate PCI devices to your virtual machine, yielding some sort of "direct hardware access".

Does that answer your question?

----------

## 1clue

Pass-through is probably what I read about, but was hoping to be able to let whatever VM was active get access, which I guess doesn't even make sense from a resources standpoint.

Thanks.

----------

## VinzC

 *1clue wrote:*   

> Pass-through is probably what I read about, but was hoping to be able to let whatever VM was active get access, which I guess doesn't even make sense from a resources standpoint.
> 
> Thanks.

 

You're welcome. Also note that on a security point of view it's no good to let a VM arbitrarily access any of the host's hardware especially without any form of control.

----------

## 1clue

Ya, I guess that makes sense too.  One big point arguing for virtualization was security, and I forgot about it in this case.

I was thinking it would be neat if the guest could "see" the hardware as it is, such that you'd use the same drivers as the host, even if you don't have genuine access.  I know it's not how things work, but somehow I was thinking, I could install a fresh host as a vm on a logical volume, compile kernels, get it stable and then reboot the host into the new image.

Emulating random hardware like that is just too big a task though, so it's an unrealistic idea.

Thanks again.

----------

## VinzC

You're making an excellent point about sharing the same driver (sort of) between the guest and the host. You have two distinct ways:

- paravirtualization with paravirt drivers in the guest (KVM and XEN support it)

- tighter coupling between the guest and host, e.g. OpenVZ.

It all depends upon what you're trying to achieve but full virtualization between two Linux systems (host and guest) doesn't make much sense in terms of performance. Of course there are advantages. But in your case — i.e. better coupling between the host and guest — I'd use OpenVZ, which shares one kernel with all its guests (also called containers). In short for virtualizing Linux on a Linux host, OpenVZ is my preferred choice. LXC also does the same.

----------

## 1clue

OK that's a lot more like what I was thinking.

Been around virtualization for years, not the good stuff but mostly desktop or developer types from VMware and Parallels (mac).  Just now getting into it for Linux, so I don't know my way around yet.

Can I use these all on the same host?  I'll read the documentation, just trying to prioritize it.

So since this is a home office I have limited hardware.  There are some VMs I already have going, and some I'd like to have going.  Can I use paravirt and/or OpenVZ in the same host system?  My business needs don't all follow the same priorities.

----------

## VinzC

 *1clue wrote:*   

> Can I use paravirt and/or OpenVZ in the same host system?  My business needs don't all follow the same priorities.

 

OpenVZ requires a rather old (read "stable") kernel tree (openvz-sources-2.6.32.*) so it might work but I don't know how the latest KVM binaries would work with such an ancient kernel. You would certainly not benefit from the latest kernel development and features. If you need both virtualization types on the same hardware node I'd suggest Linux Containers instead. Be sure to read the list of major temporary problems.

----------

## 1clue

Alas, I need 'stable' more than 'latest.'  I might need another physical box, I guess.

I have 3 scenarios where I either use VMs or want to use them:

I use VMs to provide stable network services for my home office, which may not all be on the same distro.

I use VMs to test software I write on platforms my customers use.  This includes ALL of the commercial software.

I want to use VMs to experiment with the latest greatest, and to test software using my hardware.

It seems I'll need to have two physical virtualization servers for that.  The only other scenario I can think of is to set up my host as the 'stable' one, then have a VM on there which can then host other VMs.  That doesn't seem rational to me.

Thanks.

----------

## VinzC

Hmmm... not sure you'd need two separate machines. If we take a look at the possibilities, there isKVM

Xen

OpenVZ

Linux Containers

Linux VServerXen and KVM both meet the requirements. Xen is more complex to setup though. OpenVZ is based on an older kernel hence might not give the best performance in KVM. Other than that you can chose whatever distribution you like for your Vserver/OpenVZ/LXC guests. (At least for OpenVZ as it's the only one I know.)

If we summarize it all you canuse only Xen or KVM for all your guests;

use KVM with any of LXC/Vserver (or OpenVZ if you don't mind the performance);

use KVM only and a recent kernel, plus one VM sepcifically dedicated to and optimized for OpenVZ.Just note that in terms of performance KVM has the highest score so the performance penalty is limited even virtualizing Linux/Linux, especially with virtio drivers, which provide the best performance (or the least losses if you want  :Very Happy: ).

The only scenario I'd consider a secondary machine is experimenting. It's a better idea on a separate machine in case things turn nasty, especially if you want full access to the host hardware. Other than that experimenting in a virtual machine is not that uncommon...

----------

## 1clue

OK it looks like I have quite a bit of reading to do.

Thanks for all your advice.

----------

## VinzC

It's my pleasure  :Smile:  .

Don't hesitate to provide some feedback on the solution you've chosen. I'm curious, too  :Wink:  .

----------

