[Libvir] RFC: A more convenient 'virsh create' command
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course) QEMU for example makes it very easy to launch a new VM: qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso Taking inspiration from this syntax we could allow: virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions. Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create - This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Aug 25, 2006 at 05:46:28PM +0100, Daniel P. Berrange wrote:
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course)
QEMU for example makes it very easy to launch a new VM:
qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso
Taking inspiration from this syntax we could allow:
virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo
Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions.
Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command
virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create -
This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-)
Okay, but this is dependant on the virtualization used, e.g. test and xen XML will provide different output. But with the environment variable patch this can be hidden from the command line. Either way is fine, actually the code is gonna be 90% the same, and both ways sounds useful in slightly different contexts, why not both ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, Aug 25, 2006 at 02:57:25PM -0400, Daniel Veillard wrote:
On Fri, Aug 25, 2006 at 05:46:28PM +0100, Daniel P. Berrange wrote:
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course)
QEMU for example makes it very easy to launch a new VM:
qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso
Taking inspiration from this syntax we could allow:
virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo
Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions.
Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command
virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create -
This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-)
Okay, but this is dependant on the virtualization used, e.g. test and xen XML will provide different output. But with the environment variable patch this can be hidden from the command line.
Yeah, if you don't set the env var, I'd expect the --connect parameter to be used in any case so we can easily generate appropriate XML
Either way is fine, actually the code is gonna be 90% the same, and both ways sounds useful in slightly different contexts, why not both ?
Sure :-) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Aug 25, 2006 at 05:46:28PM +0100, Daniel P. Berrange wrote:
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course)
QEMU for example makes it very easy to launch a new VM:
qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso
Taking inspiration from this syntax we could allow:
virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo
Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions.
Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command
virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create -
What use better command name instead "genxml"? For example "domgen". (we have dominfo, domstate, ...). Same odd commad name is "dumpxml"... XML of what? It should be renamed to "domdump".
This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-)
I can imagine more commands like: virsh> bufread /etc/xen/Foo.xml virsh> bufedit Foo -hdc /path/file.img virsh> create --frombuf Foo I think it could be nice for playful admins and developers. Or is over engineering? ;-) Karel -- Karel Zak <kzak@redhat.com>
On Fri, Aug 25, 2006 at 11:55:22PM +0200, Karel Zak wrote:
On Fri, Aug 25, 2006 at 05:46:28PM +0100, Daniel P. Berrange wrote:
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course)
QEMU for example makes it very easy to launch a new VM:
qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso
Taking inspiration from this syntax we could allow:
virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo
Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions.
Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command
virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create -
What use better command name instead "genxml"? For example "domgen". (we have dominfo, domstate, ...).
Same odd commad name is "dumpxml"... XML of what? It should be renamed to "domdump".
Well we can't break API - and there's a whole bunch of commands which don't start with 'dom' prefix - pause, shutdown, create, resume, vcpuinfo, setmem, setmaxmem, to name just a few - apart from nodeinfo & create essentially every command performs some kinda of operation on a domain. So I think needing to prefix all with 'dom' is a little overkill. I agree that 'genxml' is a terrible name I suggest though - domgen is nicer - or as below - just allow the args to be passed to regular create command instead of an XML file path.
This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-)
I can imagine more commands like:
virsh> bufread /etc/xen/Foo.xml virsh> bufedit Foo -hdc /path/file.img virsh> create --frombuf Foo
I think it could be nice for playful admins and developers. Or is over engineering? ;-)
A little over-engineering - if we want to let people override contents of an XML file - i'd just combine both into one, eg virsh create -hda /path/file.img /etc/xen/Foo.xml Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Aug 25, 2006 at 11:00:50PM +0100, Daniel P. Berrange wrote:
On Fri, Aug 25, 2006 at 11:55:22PM +0200, Karel Zak wrote:
On Fri, Aug 25, 2006 at 05:46:28PM +0100, Daniel P. Berrange wrote:
The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course)
QEMU for example makes it very easy to launch a new VM:
qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso
Taking inspiration from this syntax we could allow:
virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo
Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions.
Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command
virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create -
What use better command name instead "genxml"? For example "domgen". (we have dominfo, domstate, ...).
Same odd commad name is "dumpxml"... XML of what? It should be renamed to "domdump".
Well we can't break API - and there's a whole bunch of commands which don't start with 'dom' prefix - pause, shutdown, create, resume, vcpuinfo, setmem, setmaxmem, to name just a few - apart from nodeinfo & create essentially every command performs some kinda of operation on a domain. So I think needing to prefix all with 'dom' is a little overkill.
OK. Agree.
I agree that 'genxml' is a terrible name I suggest though - domgen is nicer - or as below - just allow the args to be passed to regular create command instead of an XML file path.
I think the args for the create command is nice solution, but domgen too. We should support both. I will be very happy with something like: virsh domgen -name Foo -m 256 -hda image.dsk > /etc/xen/Foo.xml
I can imagine more commands like:
virsh> bufread /etc/xen/Foo.xml virsh> bufedit Foo -hdc /path/file.img virsh> create --frombuf Foo
I think it could be nice for playful admins and developers. Or is over engineering? ;-)
A little over-engineering - if we want to let people override contents of an XML file - i'd just combine both into one, eg
virsh create -hda /path/file.img /etc/xen/Foo.xml
Good idea. Karel -- Karel Zak <kzak@redhat.com>
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Karel Zak