From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IKVi1-00064c-CB for qemu-devel@nongnu.org; Mon, 13 Aug 2007 04:55:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IKVi0-00064Q-3T for qemu-devel@nongnu.org; Mon, 13 Aug 2007 04:55:32 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IKVhz-00064N-UX for qemu-devel@nongnu.org; Mon, 13 Aug 2007 04:55:32 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IKVhz-00031y-9n for qemu-devel@nongnu.org; Mon, 13 Aug 2007 04:55:31 -0400 Message-ID: <46C01C8D.3060304@qumranet.com> Date: Mon, 13 Aug 2007 11:55:41 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images References: <59abf66e0708092155t2e3cd5o32f23c018bed65af@mail.gmail.com> <46BC8C18.6020108@codemonkey.ws> <46BC9CDB.3080900@qumranet.com> <46BCB1DA.6060102@codemonkey.ws> <46BCBF73.5060406@qumranet.com> <46BCC666.6050406@codemonkey.ws> <59abf66e0708101841i76e26a35vcbc8df14b21f1ac0@mail.gmail.com> In-Reply-To: <59abf66e0708101841i76e26a35vcbc8df14b21f1ac0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= Cc: kvm-devel@lists.sourceforge.net, qemu-devel@nongnu.org Jorge Luc=E1ngeli Obes wrote: >>> My feeling is that config files are outdated. When used with a gui, >>> you end up writing silly parsers and stuff and still wrecking things >>> horribly when the the gui writer's expectations don't match reality. >>> When used without a gui, they increase the amount of details one has >>> to remember (where's that config file? I renamed my image, did I >>> remember to update the config file?). They also make upgrading more >>> difficult. >>> =20 >> There's only so much that can be expressed on a command line. There a= re >> actually limits to the command line size on a lot of platforms. I don= 't >> see why reading options from a file is so much worse than reading them >> from the command line. >> =20 > > In my view, the bottom line is: we need an _easy_ way of launching VMs > when one doesn't want all the options of the managed approach. I back > Avi on this one, I would like to be able to do > > qemu guest.img > =20 Well, I disagree with Avi now. Dan's comment about guest images now=20 being untrusted is a killer. > without worrying about configuration files, or XML, or parsing. That's > not to say that a global configuration file for QEMU wouldn't be > useful, but I think it would solve a different problem. > > When I read Avi's TODO, I basically thought about getting rid of the > long command lines I had to store in scripts. I wanted to write that > command line once, and then forgetting about it, until I needed to > change it. I wanted an image to be self-contained as much as possible. > That's what I set to achieve. > > All that said, I rethought Anthony's idea of storing plain text in the > image and with proper tools, it can work out. I don't like the idea of > having users overwriting and padding files, but the approach seems > less of a hack than using empty snapshots. In short: I think we will > need to have something like 'qemu-img cmdline' anyways, independent of > the implementation. That's because I would like an implementation that > does not depend on extra files. For that, we already have libvirt and > the likes. > =20 I like the format-independent nature of Anthony's idea too. Basically=20 we're adding a meta-format that works along with all other formats. Anthony's other idea, to require self-contained images to be executable,=20 may be workable. I have some doubts that it is a sufficient indicator=20 of trust (though with normal shell scripts and executables it is). --=20 error compiling committee.c: too many arguments to function