KVM, virt-manager, etc.

Rick Clark rick.clark at canonical.com
Mon Jan 28 13:23:50 GMT 2008


On Monday 28 January 2008 07:19:50 Matt Zimmerman wrote:
> On Tue, Jan 22, 2008 at 10:34:56AM +0100, Soren Hansen wrote:
> > In case anyone missed my blog post about it last week, the (admittedly
> > quick and dirty) wiki page is at:
> >
> >    https://wiki.ubuntu.com/KvmVirtManagerEtc
>
> I made a few trivial changes to the page along the way as I tried this out.
> Some questions and comments:
>
>  * Is there a plan to wrap the tools or otherwise eliminate the need for
>    non-obvious command line arguments (e.g. qemu:///system)?
This argument is required because virsh/libvirt defaults to Xen.  Soren and I 
discussed wrapping this at the sprint.  It is fairly trivial and should be 
done.

>
>  * I assume it's possible to create the VM using the command-line tools as
>    well as the GUI.  Can this be added to the documentation?  Since our use
>    cases are server-oriented, I think this is important.
done

>
>  * The only option available on "Choose a virtualization method" was "fully
>    virtualized" (presumably that is expected) and "Enable kernel / hardware
>    acceleration" was disabled.  The processor in my test system (AMD
>    Athlon(tm) 64 X2 Dual Core Processor 4400+) seems to be listed on
>    http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors though
>    perhaps it is the wrong stepping.  Is there a canonical way to determine
>    whether it supports the extensions?  Linux says "stepping: 2" though AMD
>    says the two available steppings are "F2" and "E6".
A simple grep should be sufficient.  We only care what the kernel sees, since 
there are other variables that could affect the usefulness of the lists from 
Intel and AMD.

egrep ‘(vmx|svm)’ /proc/cpuinfo

That would only need to be updated when new extensions are added and not new 
CPU's

>
>  * Due to the above, I wasn't actually able to test creating a guest.  It
>    tried to invoke qemu and failed (because it wasn't installed).
>
>  * We should provide reasonable defaults for every aspect of creating a new
>    VM.  The experience we are aiming for is to enable a new Ubuntu
>    installation to have a virtual guest created immediately, with no
>    decisions necessary: this should be a single command, or
>    "next->next->next->finish" operation.
>
The GUI was originally not part of the scope.  I think it provides a good 
interface, though, and is beneficial to virtualisation on the server.  
Perhaps someone from the desktop team would be willing to help us out with 
the GUI, so the server team can focus on kvm/libvirt/virsh. 

>    - System Name can be autogenerated as a default
>
>    - Should point to an installable Ubuntu image of some sort by default. 
> I have ISOs lying around, but most servers won't.  What can we do here?
>
I think defaulting to a physical cdrom is a sane choice.


>    - Storage should default to a simple file of an appropriate size, stored
>      in a standard location (perhaps not the user's home directory)
>
I agree that their should be a default, but the vm's are owned by the user 
that creates them and the home dir seems like a sane default.  This will be 
changed by almost everyone.


>  * libvirtd failed to come up after a reboot, due to /var/run/libvirt not
>    being created.  Is this a known bug?
>
No, but this bug is related: 
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/185598

Soren has fixed this locally and it will be in the next upload.
> --
>  - mdz


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080128/106d761e/attachment.pgp 


More information about the ubuntu-devel mailing list