From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IKW5X-0002qP-Su for qemu-devel@nongnu.org; Mon, 13 Aug 2007 05:19:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IKW5X-0002qD-1K for qemu-devel@nongnu.org; Mon, 13 Aug 2007 05:19:51 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IKW5W-0002qA-NS for qemu-devel@nongnu.org; Mon, 13 Aug 2007 05:19:50 -0400 Received: from ecfrec.frec.bull.fr ([129.183.4.8]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IKW5V-0008GT-SW for qemu-devel@nongnu.org; Mon, 13 Aug 2007 05:19:50 -0400 Message-ID: <46C02216.2030503@bull.net> Date: Mon, 13 Aug 2007 11:19:18 +0200 From: Laurent Vivier 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> <46C01C8D.3060304@qumranet.com> In-Reply-To: <46C01C8D.3060304@qumranet.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6E10F7D1F618FAA0934DD448" Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kvm-devel@lists.sourceforge.net, =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6E10F7D1F618FAA0934DD448 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > 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 = are >>> actually limits to the command line size on a lot of platforms. I do= n't >>> see why reading options from a file is so much worse than reading the= m >>> 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 >=20 > Well, I disagree with Avi now. Dan's comment about guest images now > being untrusted is a killer. >=20 >> 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 >=20 > I like the format-independent nature of Anthony's idea too. Basically > we're adding a meta-format that works along with all other formats. >=20 > Anthony's other idea, to require self-contained images to be executable= , > may be workable. I have some doubts that it is a sufficient indicator > of trust (though with normal shell scripts and executables it is). I know we are not in democracy, but if I can vote I'd like to vote to the= idea of Christian Brunschen... We can modify qemu to test if the argument is a directory, if yes, it rea= ds args from file args in this directory and for security the disk image must be = in the same directory. for instance, we have: =2E/pc1/ =2E/pc1/args =2E/pc1/my_disk and in ./pc1/args, we have "-hda my_disk" and when we run "qemu pc1", it starts "qemu -hda ./pc1/my_disk" I don't like the idea of the config file (when it is complex it is very h= ard to have a correct one like for Xen or like for Xorg) I don't like the idea of Anthony because it looks like a hack . Laurent, the killjoy --=20 ------------- Laurent.Vivier@bull.net -------------- "Software is hard" - Donald Knuth --------------enig6E10F7D1F618FAA0934DD448 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQFGwCIZ9Kffa9pFVzwRAokZAJ9KVek0dH+rLFmMkIJBrhbAJdLvIQCgnjc7 zrbt8OZJy1LP4l9SA2jrm+o= =CN1s -----END PGP SIGNATURE----- --------------enig6E10F7D1F618FAA0934DD448--