Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
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. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing IMHO, it should be implemented at the shell level, not qemu level, like * is. The shell _does_ implement it: qemu `cat qemu.cfg` :-) If you want @ anyway, you can pick up the code from libiberty (or just build with libiberty). Segher
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes schrieb: qemu: could not open hard disk image '@config' I think this was a suggestion for implementation, not a working feature. I did not know about '@config', and if I can get it to work, I like it better than a shell script. However, I think it does not completely solve the problem. It still means two files per VM. As long as it is not possible to store more than one image in one file, this problem won't be solved completely anyway. Kevin
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Thiemo Seufer wrote: Jorge Lucángeli Obes wrote: [snip] 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. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing IMHO, it should be implemented at the shell level, not qemu level, like * is. Laurent -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 14 Aug 2007, at 00:31, Thiemo Seufer wrote: Philip Boulain wrote: On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: ...implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I don't think it has anything to do with bash. Apparently Windows(NT) cmd.exe introduced this as a way to avoid unwieldy command lines. Cygwin (or MingGW?) added the same to their tools in order to avoid command line length problems. Not so long ago it was implemented for gcc and binutils... Ugh. This is in-application magic that does a pre-parsing step on argv []? I'm suddenly being flooded with horrible memories of how Win-DOS requires each individual application to implement its own wildcards in arguments, and how these implementations were inevitably inconsistent in ways that stabbed you in the face. Maybe QEMU /should/ have a ...and read this file as arguments... argument, but this really doesn't seem a good way to do it. -c qemu.cfg is a lot less ambiguous, as you don't have to worry about whether an '@' in an argument is an include command, or a literal, e.g. part of a filename (it could be either, and escaping it at the shell level won't help). LionsPhil
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Avi Kivity wrote: Jorge Lucángeli 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. 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 don't see why reading options from a file is so much worse than reading them from the command line. 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 Well, I disagree with Avi now. Dan's comment about guest images now 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. 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. 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 reads args from file args in this directory and for security the disk image must be in the same directory. for instance, we have: ./pc1/ ./pc1/args ./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 hard 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 -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Laurent Vivier [EMAIL PROTECTED] wrote: 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 reads args from file args in this directory and for security the disk image must be in the same directory. I'd like to also vote for this solution, as I believe it's portable for windows hosts and generic enough to satisfy most needs. Christian
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes wrote: [snip] 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. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) I wanted an image to be self-contained as much as possible. That's what I set to achieve. Which tends to collect all the complexity in a single piece. That seems to be the common problem of the option discussed here. All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. Requiring proper tools doesn't leave much of a point for plain text. Thiemo
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) except it does not work yet on Windows! I tried with a 1 line file (all arguments on 1 line) and another file with each pair of arguments per line. qemu.exe @detaolb.cfg qemu: could not open hard disk image '@detaolb.cfg' type detaolb.cfg -L bios -m 128 -cdrom detaolb_v04.iso -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I wanted an image to be self-contained as much as possible. That's what I set to achieve. Which tends to collect all the complexity in a single piece. That seems to be the common problem of the option discussed here. As far as I can tell, this is desirable for easy distribution of images to other machines; this is pretty much my only objection to the 'directory' idea, which is otherwise a nice, clean solution. (If not, I can't really see what's wrong with a one-liner sh script alongside the image, which is basically what has been reinvented.) All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. Requiring proper tools doesn't leave much of a point for plain text. Correct, but qemu's command-line arguments (and it makes sense to use the same syntax for embedded ones, such that the parser can be re- used) /are/ plain text. Still, it's probably worth thinking of it as a shebang and a serialised (subset of) argv[], rather than /a command line/. In particular, you can avoid having to do sh's job of splitting and escaping again. LionsPhil
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/14/07, Anthony Liguori [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 20:39 +0100, Thiemo Seufer wrote: Jorge Lucángeli Obes wrote: [snip] 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. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) In this case, it's also just as easy to make a shell script. I think an important goal here is to automatically associate the options for a VM with the actual disk image. It's not just about storing said options in a file. On my 64-bit Xubuntu Feisty I get: qemu: could not open hard disk image '@config' Anyways, as Anthony said, we would like to have only one file describing the VM. Since we already have the disk image, we were looking for ways to reuse that image for this purpose. I did not know about '@config', and if I can get it to work, I like it better than a shell script. However, I think it does not completely solve the problem. It still means two files per VM. Cheers, Jorge
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Avi Kivity wrote: This is a big effort but a config file is the right long term solution. For which use case? management-full or management-less? Both. A config file will be useful not just for expressing the functionality we have today, but also for describing the guest's environment in greater detail. For instance, if you want to support a bunch of different kinds of embedded systems, it would be very nice if the machine description was a config file instead of hard coded such that it was easy to tweak what hardware was present for the particular embedded system. A managed system will want to supply arguments out of a central database. For a management-less use case, the config file is a hassle. As long as all options are still settable via command line (or stdio), then it's not at all a hassle. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ kvm-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Avi Kivity wrote: Anthony Liguori wrote: Avi Kivity wrote: This is a big effort but a config file is the right long term solution. For which use case? management-full or management-less? Both. A config file will be useful not just for expressing the functionality we have today, but also for describing the guest's environment in greater detail. For instance, if you want to support a bunch of different kinds of embedded systems, it would be very nice if the machine description was a config file instead of hard coded such that it was easy to tweak what hardware was present for the particular embedded system. Maybe I'm dense today. Which use case is this? If you're using QEMU to simulate an embedded platform (ARM or PPC based for instance). There is a huge amount of variety in embedded platforms so having to hard code the PC description as a machine type in QEMU is kind of annoying. A managed system will want to supply arguments out of a central database. For a management-less use case, the config file is a hassle. As long as all options are still settable via command line (or stdio), then it's not at all a hassle. Yes. But if you don't plan to use it, why implement it? Well, I do plan to use it. I'm simply saying that you don't have to use it if you don't want to. There are a lot of knobs in QEMU and most of them have somewhat arbitrary defaults. For instance, when I setup a machine, I don't want to use user networking by default, I want to use tap. A global configuration file would be terribly useful for this sort of thing. 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. 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 don't see why reading options from a file is so much worse than reading them from the command line. Regards, Anthony Liguori
