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 > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Anthony Liguori wrote: > Jorge Lucángeli Obes wrote: >> Hi all, >> >> >From what I've gathered, it seems that we have basically four options >> at hand. I think it's important to notice, however, that whatever >> comes out of this will probably be, as Avi said, a "low-end" solution. >> IMHO there's room to have both the high-end libvirt-like approach, and >> the "shell replacer" approach. >> >> So let's see: >> >> 1- We could go the way of the patches I've posted, adding the comments >> everyone's made. >> 1a- It's a good idea to actively signal QEMU to read command line >> options from the image file, and not have it on by default. >> > > I think if you have to add a new option, the base implementation is > wrong. The whole point of this is to simplify things for the user and > adding more weird options just makes things more complicated. It's not as bad as that -- the user has to remember only option (or have a qemu-trusted script that supplies the option). But I agree that the feature is now much less compelling, and that the new option is needed. > >> 4- We could have configuration files associated with the host and >> guests. >> 4a- Embedded XML. >> 4b- Separate files. >> > > This is a big effort but a config file is the right long term solution. > For which use case? management-full or management-less? 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. - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
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? >> 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? 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. - 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 kvm-devel@lists.sourceforge.net 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 > > > - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
> > 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 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. Cheers, Jorge - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
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). -- error compiling committee.c: too many arguments to function - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
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. Regards, Anthony Liguori > > 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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Markus Hitter wrote: > > Am 13.08.2007 um 11:19 schrieb Laurent Vivier: > >> 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 "-hdb ../pc2/my_other_disk" If we want to preserve security we should forbid this, but you can make a soft link: ln -s shared_disks/my_disk1 pc1/my_shared_disk ln -s shared_disks/my_disk1 pc2/my_shared_disk and have pc1/args and pc2/args = "-hda my_disk -hdb my_shared_disk" to have: qemu -hda pc1/my_disk -hdb pc1/my_shared_disk qemu -hda pc2/my_disk and -hdb pc2/my_shared_disk > The directory idea sounds good. Especially for me, as I'm obviously the > only one running one disk image in different virtual machines. > > Plus, it'd work for physical partitions / disks: Simply have a directory > with an "args" file only. > > > my $ 0.01 > Markus > > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > > > > -- - [EMAIL PROTECTED] -- "Software is hard" - Donald Knuth signature.asc Description: OpenPGP digital signature - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Am 13.08.2007 um 11:19 schrieb Laurent Vivier: > 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 "-hdb ../pc2/my_other_disk" The directory idea sounds good. Especially for me, as I'm obviously the only one running one disk image in different virtual machines. Plus, it'd work for physical partitions / disks: Simply have a directory with an "args" file only. my $ 0.01 Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/14/07, Laurent Vivier <[EMAIL PROTECTED]> wrote: > Markus Hitter wrote: > > > > Am 13.08.2007 um 11:19 schrieb Laurent Vivier: > > > >> 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 "-hdb ../pc2/my_other_disk" > > If we want to preserve security we should forbid this, but you can make a > soft link: > > ln -s shared_disks/my_disk1 pc1/my_shared_disk > ln -s shared_disks/my_disk1 pc2/my_shared_disk > > and have pc1/args and pc2/args = "-hda my_disk -hdb my_shared_disk" > to have: > > qemu -hda pc1/my_disk -hdb pc1/my_shared_disk > > qemu -hda pc2/my_disk and -hdb pc2/my_shared_disk > > > The directory idea sounds good. Especially for me, as I'm obviously the > > only one running one disk image in different virtual machines. > > > > Plus, it'd work for physical partitions / disks: Simply have a directory > > with an "args" file only. > > > > > > my $ 0.01 > > Markus Quoting Thiemo, this '@' thing was "a feature which is now implemented in the GNU toolchain". That's why I tried it. Now I would like to know what he did to get it working. It would certainly be an useful feature, even if it does not exactly suit our purposes. I still think that the executable-image approach could work nicely. However, the point in favour of a configuration directory when using physical partitions or disks is good. Nonetheless, a physical partition is much less "volatile" than an disk image, so the disadvantage of keeping a shell script is small in that case. Cheers, Jorge - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes wrote: [snip] > Quoting Thiemo, this '@' thing was "a feature which is now implemented > in the GNU toolchain". That's why I tried it. Now I would like to know > what he did to get it working. It would certainly be an useful > feature, even if it does not exactly suit our purposes. Apparently I managed to create some misunderstanding. :-) The @file feature was implemented in/for the _tools_ of the GNU toolchain. It is not meant to become a general feature of all linux userland applications. Thiemo - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
yet colinux >= 0.7.1 is using I believe a similar approach for passing its parameters... quoting the readme: "colinux-daemon @example.conf" and this is what I use on a daily basis to compile detaolb on colinux (which I test later using qemu). On 8/14/07, Thiemo Seufer <[EMAIL PROTECTED]> wrote: > Jorge Lucángeli Obes wrote: > [snip] > > Quoting Thiemo, this '@' thing was "a feature which is now implemented > > in the GNU toolchain". That's why I tried it. Now I would like to know > > what he did to get it working. It would certainly be an useful > > feature, even if it does not exactly suit our purposes. > > Apparently I managed to create some misunderstanding. :-) > The @file feature was implemented in/for the _tools_ of the GNU > toolchain. It is not meant to become a general feature of all > linux userland applications. > > > Thiemo > > > -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
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 - 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 kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
