linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Mar 2010 17:28:15 +0700
From:	Antoine Martin <antoine@...afix.co.uk>
To:	Kevin Wolf <kwolf@...hat.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>,
	Gregory Haskins <ghaskins@...ell.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

On 03/23/2010 05:13 PM, Kevin Wolf wrote:
> Am 22.03.2010 23:06, schrieb Anthony Liguori:
>    
>> On 03/22/2010 02:47 PM, Avi Kivity wrote:
>>      
>>> Having qemu enumerate guests one way or another is not a good idea IMO
>>> since it is focused on one guest and doesn't have a system-wide entity.
>>>        
>> There always needs to be a system wide entity.  There are two ways to
>> enumerate instances from that system wide entity.  You can centralize
>> the creation of instances and there by maintain an list of current
>> instances.  You can also allow instances to be created in a
>> decentralized manner and provide a standard mechanism for instances to
>> register themselves with the system wide entity.
>>
>> IOW, it's the difference between asking libvirtd to exec(qemu) vs
>> allowing a user to exec(qemu) and having qemu connect to a well known
>> unix domain socket for libvirt to tell libvirtd that it exists.
>>      
> I think the latter is exactly what I would want for myself. I do see the
> advantages of having a central instance, but I really don't want to
> bother with libvirt configuration files or even GUIs just to get an
> ad-hoc VM up when I can simply run "qemu -hda hd.img -m 1024". Let alone
> that I usually want to have full control over qemu, including monitor
> access and small details available as command line options.
>
> I know that I'm not the average user with these requirements, but still
> I am one user and do have these requirements. If I could just install
> libvirt, continue using qemu as I always did and libvirt picked my VMs
> up for things like global enumeration, that would be more or less the
> optimal thing for me.
>    
+1
And it would also make it more likely that users like us would convert 
to libvirt in the long run, by providing an easy and integrated 
transition path.
I've had another look at libvirt, and one of the things that is holding 
me back is the cost of moving existing scripts to libvirt. If it could 
just pick up what I have (at least in part), then I don't have to.

Antoine

> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/