[Qemu-devel] Storing command line options in images

[Qemu-devel] Storing command line options in images

[Jorge Lucángeli Obes]

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.
1b- As Avi said, there are many guest-related options that would be
good to store _somewhere_. The user always has the option of using
qemu-img to review the options that the VM is going to use. I think
that having a "valid" set of options that the user can store will
complicate things too much.

2- We could bump qcow's version number and add command line options as
"first-class citizens" of the image world.
2a- As Anthony suggested, it could be a good starting point to make
sure these version transition happen in a smoother way.

3- We could add command line options as plain text in the image
itself. Sounds (to me) risky and not very user friendly.

4- We could have configuration files associated with the host and guests.
4a- Embedded XML.
4b- Separate files.

What do you guys think? I'm partial to 1 or 2. Since the beginning my
approach was that of a simple solution for a simple feature.

Cheers,
Jorge

[Qemu-devel] Re: [kvm-devel] Storing command line options in images

[Anthony Liguori]

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.

> 1b- As Avi said, there are many guest-related options that would be
> good to store _somewhere_. The user always has the option of using
> qemu-img to review the options that the VM is going to use. I think
> that having a "valid" set of options that the user can store will
> complicate things too much.
>
> 2- We could bump qcow's version number and add command line options as
> "first-class citizens" of the image world.
> 2a- As Anthony suggested, it could be a good starting point to make
> sure these version transition happen in a smoother way.
>
> 3- We could add command line options as plain text in the image
> itself. Sounds (to me) risky and not very user friendly.
>   

Why is it risky or user unfriendly?  From the user's perspective, it's 
no different from storing it in a snapshot.  The user still needs a 
separate tool (qemu-img) to view and manipulate the command line.  The 
only real user facing difference is that the image itself is now 
directly executable.  This turns out to be a Good Thing in that the user 
is now aware that he must trust that image which addresses the concern 
in 1a.

> 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.

Regards,

Anthony Liguori

> What do you guys think? I'm partial to 1 or 2. Since the beginning my
> approach was that of a simple solution for a simple feature.
>
> 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: [Qemu-devel] Re: [kvm-devel] Storing command line options in images

[Avi Kivity]

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.

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Anthony Liguori]

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
>
>   

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Avi Kivity]

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.

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Anthony Liguori]

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

>
>
>

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Jorge Lucángeli Obes]

> > 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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Avi Kivity]

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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 3391 bytes --]

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
-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Christian MICHON]

On 8/13/07, Laurent Vivier <Laurent.Vivier@bull.net> 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

[Markus Hitter]

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/

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

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/
> 
> 
> 
> 
> 
> 
> 


-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Jorge Lucángeli Obes]

On 8/14/07, Laurent Vivier <Laurent.Vivier@bull.net> 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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Thiemo Seufer]

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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Christian MICHON]

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 <ths@networkno.de> 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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Thiemo Seufer]

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

[Christian MICHON]

On 8/13/07, Thiemo Seufer <ths@networkno.de> 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

[Philip Boulain]

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

[Qemu-devel] Re: [kvm-devel] Storing command line options in images

[Jernej Simončič]

On Tuesday, August 14, 2007, 0:21:42, Philip Boulain wrote:

>>   qemu @qemu.cfg
> I'm not familiar with that. Is it just GNU bash shorthand for  qemu
> `cat qemu.cfg`  ?

GNU bash does not have that shorthand, but @file is very similar to
`cat file` (the practice was born in DOS days, because the command
line was limited to 127 characters).

-- 
< Jernej Simončič ><><><><>< http://deepthought.ena.si/ >

A coup that is known in advance is a coup that does not take place.
       -- Camp's Law

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Thiemo Seufer]

Philip Boulain wrote:
> 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 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, both as a way to pass overlong argument lists and
to allow for easier scripting.

>>> 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.)

It would be a sh script plus a cmd script plus whatever OS X may need
some day, all of them copying the same option line. @file would avoid
that (and allow generic wrapper scripts).


Thiemo

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Philip Boulain]

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

[Anthony Liguori]

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

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Jorge Lucángeli Obes]

On 8/14/07, Anthony Liguori <anthony@codemonkey.ws> 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

[Kevin Wolf]

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

[Laurent Vivier]

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

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
-- 
------------- Laurent.Vivier@bull.net  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images

[Segher Boessenkool]

>>> 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