linux next: Native Linux KVM tool inclusion request

linux next: Native Linux KVM tool inclusion request

[Sasha Levin]

Hello Stephen,

I would like to ask you to include the Native Linux KVM tool in the
linux-next tree.

The branch is named 'master' and is located in:

	git://github.com/penberg/linux-kvm.git


Thanks!

-- 

Sasha.

Re: linux next: Native Linux KVM tool inclusion request

[Christoph Hellwig]

On Mon, Aug 22, 2011 at 11:29:20PM +0300, Sasha Levin wrote:
> Hello Stephen,
> 
> I would like to ask you to include the Native Linux KVM tool in the
> linux-next tree.

What has changed over the last rejection of it?  Again, I'm not against
the tool, but there is no reason to throw it into the kernel tree with
a completely misleading name.

Re: linux next: Native Linux KVM tool inclusion request

[Pekka Enberg]

On Mon, Aug 22, 2011 at 11:29:20PM +0300, Sasha Levin wrote:
>> I would like to ask you to include the Native Linux KVM tool in the
>> linux-next tree.

On Tue, Aug 23, 2011 at 3:39 AM, Christoph Hellwig <hch@infradead.org> wrote:
> What has changed over the last rejection of it?  Again, I'm not against
> the tool, but there is no reason to throw it into the kernel tree with
> a completely misleading name.

Linus didn't reject it but postponed his decision to the next merge
window. We're going to send a pull request for 3.2 so we'd like the
code to be in linux-next.

As for changes, we've implemented rootfs over 9p with "kvm run"
booting to host filesystem "/bin/sh" by default. It still needs some
work and we hope to enable networking too. We also have patches to use
overlayfs so that the guest is able to use host filesystem in
copy-on-write manner.

                        Pekka

Re: linux next: Native Linux KVM tool inclusion request

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

Hi all,

On Tue, 23 Aug 2011 08:08:02 +0300 Pekka Enberg <penberg@kernel.org> wrote:
>
> On Mon, Aug 22, 2011 at 11:29:20PM +0300, Sasha Levin wrote:
> >> I would like to ask you to include the Native Linux KVM tool in the
> >> linux-next tree.
> 
> On Tue, Aug 23, 2011 at 3:39 AM, Christoph Hellwig <hch@infradead.org> wrote:
> > What has changed over the last rejection of it?  Again, I'm not against
> > the tool, but there is no reason to throw it into the kernel tree with
> > a completely misleading name.
> 
> Linus didn't reject it but postponed his decision to the next merge
> window. We're going to send a pull request for 3.2 so we'd like the
> code to be in linux-next.
> 
> As for changes, we've implemented rootfs over 9p with "kvm run"
> booting to host filesystem "/bin/sh" by default. It still needs some
> work and we hope to enable networking too. We also have patches to use
> overlayfs so that the guest is able to use host filesystem in
> copy-on-write manner.

I will add this to linux-next tomorrow unless people object by then.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux next: Native Linux KVM tool inclusion request

[Pekka Enberg]

On Tue, Aug 23, 2011 at 9:58 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> I will add this to linux-next tomorrow unless people object by then.

Thanks. The code won't cause harm to anyone as it's all under
tools/kvm and doesn't affect people who don't want to use it.

                        Pekka

Re: linux next: Native Linux KVM tool inclusion request

[Avi Kivity]

On 08/23/2011 08:08 AM, Pekka Enberg wrote:
> As for changes, we've implemented rootfs over 9p with "kvm run"
> booting to host filesystem "/bin/sh" by default.

Isn't this dangerous?  Users expect virtualization to land them in 
sandbox, but here an rm -rf / in the guest will happily junk the host 
filesystem.

> It still needs some
> work and we hope to enable networking too. We also have patches to use
> overlayfs so that the guest is able to use host filesystem in
> copy-on-write manner.
>

Still dangerous (but just to the guest), since it's not a true 
snapshot.  If the host filesystem changes underneath the guest, it will 
see partial and incoherent updates.  Copy-on-write only works if the 
host filesystem doesn't change.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: linux next: Native Linux KVM tool inclusion request

[Pekka Enberg]

On 8/24/11 11:31 AM, Avi Kivity wrote:
> On 08/23/2011 08:08 AM, Pekka Enberg wrote:
>> As for changes, we've implemented rootfs over 9p with "kvm run"
>> booting to host filesystem "/bin/sh" by default.
>
> Isn't this dangerous?  Users expect virtualization to land them in 
> sandbox, but here an rm -rf / in the guest will happily junk the host 
> filesystem.

Not really because I never run the tool as root. However, you're right that
we should not default to /bin/sh if you're root.

>> It still needs some
>> work and we hope to enable networking too. We also have patches to use
>> overlayfs so that the guest is able to use host filesystem in
>> copy-on-write manner.
>
> Still dangerous (but just to the guest), since it's not a true 
> snapshot.  If the host filesystem changes underneath the guest, it 
> will see partial and incoherent updates.  Copy-on-write only works if 
> the host filesystem doesn't change.

That's a generic problem with overlayfs based solutions, isn't it? We're 
planning
to use copy-on-write only on files that aren't supposed to change that 
often -
like /usr and /lib. I suppose we should force shared files to be 
read-only in
the guest.

                                     Pekka

Re: linux next: Native Linux KVM tool inclusion request

[Avi Kivity]

On 08/24/2011 12:19 PM, Pekka Enberg wrote:
> On 8/24/11 11:31 AM, Avi Kivity wrote:
>> On 08/23/2011 08:08 AM, Pekka Enberg wrote:
>>> As for changes, we've implemented rootfs over 9p with "kvm run"
>>> booting to host filesystem "/bin/sh" by default.
>>
>> Isn't this dangerous?  Users expect virtualization to land them in 
>> sandbox, but here an rm -rf / in the guest will happily junk the host 
>> filesystem.
>
> Not really because I never run the tool as root. However, you're right 
> that
> we should not default to /bin/sh if you're root.

Well, just trashing /home/penberg would be bad too, no? (my recent 
experience indicates it's not that catastrophic - anything important 
sits on a server somewhere and the local data is just a cache).

>>
>> Still dangerous (but just to the guest), since it's not a true 
>> snapshot.  If the host filesystem changes underneath the guest, it 
>> will see partial and incoherent updates.  Copy-on-write only works if 
>> the host filesystem doesn't change.
>
> That's a generic problem with overlayfs based solutions, isn't it? 
> We're planning
> to use copy-on-write only on files that aren't supposed to change that 
> often -
> like /usr and /lib.

So the guest won't see bad data that often?

Overlay works fine if the host tree is readonly.  So if you have a 
separate tree for guests, you can share it with any number of them.  
Just don't share the host root.

Note this probably isn't a problem booting to /bin/bash, just booting a 
full-featured guest with package management and other database-like apps 
that expect exclusive control over their data.

> I suppose we should force shared files to be read-only in
> the guest.
>

Yes, that's safer.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

Re: linux next: Native Linux KVM tool inclusion request

[Pekka Enberg]

On 8/24/11 12:33 PM, Avi Kivity wrote:
> Well, just trashing /home/penberg would be bad too, no? (my recent 
> experience indicates it's not that catastrophic - anything important 
> sits on a server somewhere and the local data is just a cache).

Sure. We actually are planning something like this:

   Private to guest:

   /dev
   /etc
   /home
   /proc
   /sys
   /var

   Shared from host rootfs:

   /bin
   /lib
   /sbin
   /usr

   Full host rootfs mounted at:

   /host/

And no, we're not planning to boot full distro init. The only thing we
really want in addition to /bin/sh is to enable networking.

                                 Pekka

Re: linux next: Native Linux KVM tool inclusion request

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

Hi Sasha,

On Mon, 22 Aug 2011 23:29:20 +0300 Sasha Levin <levinsasha928@gmail.com> wrote:
>
> I would like to ask you to include the Native Linux KVM tool in the
> linux-next tree.
> 
> The branch is named 'master' and is located in:
> 
> 	git://github.com/penberg/linux-kvm.git

I have included your tree from today and called it "kvmtool". I have you
and Pekka currently listed as teh contacts (since it looks like it is his
tree on github).  Please consider adding a MAINTAINERS entry for this.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgment of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window. 

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
	Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and 
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

-- 
Cheers,
Stephen Rothwell 
sfr@canb.auug.org.au

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: linux next: Native Linux KVM tool inclusion request

[Sasha Levin]

On Wed, 2011-08-24 at 11:52 +1000, Stephen Rothwell wrote:
> Hi Sasha,
> 
> On Mon, 22 Aug 2011 23:29:20 +0300 Sasha Levin <levinsasha928@gmail.com> wrote:
> >
> > I would like to ask you to include the Native Linux KVM tool in the
> > linux-next tree.
> > 
> > The branch is named 'master' and is located in:
> > 
> > 	git://github.com/penberg/linux-kvm.git
> 
> I have included your tree from today and called it "kvmtool". I have you
> and Pekka currently listed as teh contacts (since it looks like it is his
> tree on github).  Please consider adding a MAINTAINERS entry for this.
> 
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window. 
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
> 	Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and 
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.
> 

Thank you for the inclusion.

We will add a MAINTAINERS file.

-- 

Sasha.