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