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

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

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.

> 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