Re: automatically starting KVM
On Wed, 23 Dec 2015 21:18:39 -0500 Jason White via luv-main <luv-main@luv.asn.au> wrote:
Russell Coker via luv-main <luv-main@luv.asn.au> wrote:
To run KVM virtual machines it seems to be recommended to un virsh which requires XML.
I've run kvm guests directly, without virsh installed, while also managing them from the console. Thus, whether you actually need virsh depends on your requirements and environment.
What you are saying is true, But inmho, virsh give you far more control over the VM (eg: snapshots, connecting devices live etc). While you may be able to do the same without virsh, using it to me is much easier, specially if you are doing it remotely. Cheers, Daniel
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- dan062 <dan062@yahoo.com.au> -- dan062 <dan062@yahoo.com.au>
On Thu, 24 Dec 2015 02:27:07 PM Dan062 via luv-main wrote:
I've run kvm guests directly, without virsh installed, while also managing them from the console. Thus, whether you actually need virsh depends on your requirements and environment.
What you are saying is true, But inmho, virsh give you far more control over the VM (eg: snapshots, connecting devices live etc). While you may be able to do the same without virsh, using it to me is much easier, specially if you are doing it remotely.
Virsh does seem to have some nice features, but I don't really need them. All I want is start, stop, and console access. That said I'll investigate Craig's suggestions to see if I can make virsh do what I want, that would be the easiest solution. Thanks for the suggestions! -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
virsh is very simple, no XML editing required. # virsh help autostart NAME autostart - autostart a domain SYNOPSIS autostart <domain> [--disable] DESCRIPTION Configure a domain to be automatically started at boot. OPTIONS [--domain] <string> domain name, id or uuid --disable disable autostarting Cheers A.
On 27/12/2015 6:57 PM, Andrew McGlashan via luv-main wrote:
virsh is very simple, no XML editing required.
# virsh help autostart NAME autostart - autostart a domain
SYNOPSIS autostart <domain> [--disable]
DESCRIPTION Configure a domain to be automatically started at boot.
OPTIONS [--domain] <string> domain name, id or uuid --disable disable autostarting
Just a couple of quick examples from the cmd line. # virsh autostart example.com Domain example.com marked as autostarted # virsh autostart example.com --disable Domain example.com unmarked as autostarted # virsh dominfo example.com Id: - Name: example.com UUID: 3581bbbb-84c9-5e5e-ada5-2dd39431c100 OS Type: hvm State: shut off CPU(s): 1 Max memory: 524288 KiB Used memory: 524288 KiB Persistent: yes Autostart: disable Managed save: no A.
Andrew McGlashan via luv-main <luv-main@luv.asn.au> writes:
On 27/12/2015 6:57 PM, Andrew McGlashan via luv-main wrote:
virsh is very simple, no XML editing required.
Just a couple of quick examples from the cmd line.
# virsh autostart example.com # virsh autostart example.com --disable # virsh dominfo example.com Id: - Name: example.com UUID: 3581bbbb-84c9-5e5e-ada5-2dd39431c100 OS Type: hvm State: shut off CPU(s): 1 Max memory: 524288 KiB Used memory: 524288 KiB Persistent: yes Autostart: disable Managed save: no
Without using "virsh edit" or "virsh dumpxml", how do you do things like... * use virtio for all the things * enable serial & disable VNC * change the RAM cap from 2GB to 8GB * add /srv/kvm/foo.qcow2 visible to the guest as /dev/vdc * add a second NIC on bridge br-foo with mac dead.beef.babe Currently I do that with "virsh edit" and some cargo-culting. For great justice, "virsh edit" includes lots of read-only options, (e.g. how much RAM is CURRENTLY used) so sometimes it takes me a few goes.
On Tue, Dec 29, 2015 at 02:24:39PM +1100, Trent W. Buck wrote:
On 27/12/2015 6:57 PM, Andrew McGlashan wrote:
virsh is very simple, no XML editing required.
Without using "virsh edit" or "virsh dumpxml", how do you do things like...
I would also argue that virsh's CLI isn't that simple, either. Given that there are 223 commands across 12 groups, each with their own set of arguments and options. Often with an inconsistent interfaces, e.g. + list, <command>-list, <command>list, <command> --list + which take individual --options to filter results (rather than one --filter option, or not at all, and just pipe to a filter command) + Separate commands for essentially the same function, could be condensed into one command with options; e.g. define, create, create-as, create-from, + vol-* commands take either a <vol> or <pool> argument, many commands to display vol attributes, rather than one command with options, or filters + blkdeviotune vs blkiotune vs block* commands + Some commands take XML file as an argument, but others to print the XML configuration + Probably some more I've forgotten, or haven't noticed. Although the following would be more verbose, it would go a long way towards consistency, using a "command verb object options" pattern; $ virsh create [domain|volume|etc] --name <name> <options> $ virsh create domain --file <xml-file> $ virsh info domain <domain> --dumpxml <xml-file> $ virsh create snapshot <domain> $ virsh clone volume <volume> [options] $ virsh list network --filter active [options] $ virsh edit [domain|network|pool|etc] Just a thought... any one else think that'd be a good idea?
On 30/12/2015 12:41 am, Joel W. Shea wrote:
Although the following would be more verbose, it would go a long way towards consistency, using a "command verb object options" pattern;
$ virsh create [domain|volume|etc] --name <name> <options> $ virsh create domain --file <xml-file> $ virsh info domain <domain> --dumpxml <xml-file> $ virsh create snapshot <domain> $ virsh clone volume <volume> [options] $ virsh list network --filter active [options] $ virsh edit [domain|network|pool|etc]
Just a thought... any one else think that'd be a good idea?
Be a great idea, I hate virsh right now just so hard to find the correct command and some of this are just wrong. Mike
participants (6)
-
Andrew McGlashan -
Dan062 -
Joel W. Shea -
Mike O'Connor -
Russell Coker -
trentbuck＠gmail.com