Storing command line options in images

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

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

Re: 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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> 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/

Re: [Qemu-devel] Re: 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.


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

Re: [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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> 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/

Re: [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.




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

Re: [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

>
>
>


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

Re: [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

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

Re: [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


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

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

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 3411 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-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


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

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: [kvm-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] 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: [Qemu-devel] Re: Storing command line options in images

[Christian MICHON]

On 8/13/07, Thiemo Seufer <ths-eH4hzgmiRX8dwXzzRB9H2Q@public.gmane.org> 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/

Re: [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


-------------------------------------------------------------------------
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: Storing command line options in images

[Jorge Lucángeli Obes]

On 8/14/07, Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org> 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/

Re: [kvm-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] 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: [Qemu-devel] Re: Storing command line options in images

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 1360 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-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


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

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

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

[Jorge Lucángeli Obes]

On 8/14/07, Laurent Vivier <Laurent.Vivier-6ktuUTfB/bM@public.gmane.org> 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/

Re: [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

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

Re: [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-eH4hzgmiRX8dwXzzRB9H2Q@public.gmane.org> 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/

Re: [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


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