[libvirt] Have any commands in libvirt to run a domain

Hi all,

Are there any commands in console to start/suspend/resume/stop a domain?
Is it possible to start a domain as following command:

# libvirt-command -cpu <cpu cycle> -mem <memory> -disk <disk quota>
-network <network bandwith> -template <windows>

If not, can I build this command with existing libvirt API?

Thanks,

Ian

[libvirt] [PATCH] set cache=off on -disk line in qemu driver if <shareable/> (but not <readonly/>) is set.

As cache=off is necessary for clustering filesystems such as GFS (and 
such is the point of shareable, yes?), I believe this is correct behavior.

Comments?

As cache=off is necessary for clustering filesystems such as GFS (and 
such is the point of shareable, yes?), I believe this is correct behavior.

Comments?

[libvirt] Error setting up graphics device:list index out of range

When I try to create a new KVM VM x86_64, os variant Ubuntu Hardy, it 
fails at the end with this message:

Error setting up graphics device:list index out of range

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/create.py", line 640, in 
finish
    guest._graphics_dev = virtinst.VirtualGraphics
(type=virtinst.VirtualGraphics.TYPE_VNC)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 207, in 
__init__
    self.set_keymap(keymap)
  File "/usr/lib/python2.5/site-packages/virtinst/Guest.py", line 219, in 
set_keymap
    val = util.default_keymap()
  File "/usr/lib/python2.5/site-packages/virtinst/util.py", line 293, in 
default_keymap
    kt = s.split('"')[1]
IndexError: list index out of range

What could be wrong here? I'm using virt-manager 0.6.0, libvirt 0.4.6, 
python-virtinst 0.400.0 on Mandriva Linux 2009.0 x86_64.

--

-- 
Frederik Himpe

Re: [libvirt] [PATCH]: Allow arbitrary paths to virStorageVolLookupByPath

On Fri, Oct 31, 2008 at 12:58:17PM +0100, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> >> Personally, I think those are bad semantics for virStorageBackendStablePath;
> >> assuming it succeeds, you should always be able to know that you have a copy,
> >> regardless of whether the copy is the same as the original.  Should I change
> >> virStorageBackendStablePath to those semantics, in which case your below code
> >> would then be correct?
> > 
> > Yes, I think that's worth doing - will also avoid the cast in the input
> > arg there
> 
> OK, updated patch attached; virStorageBackendStablePath now always returns a
> copy of the given string, so it's always safe to unconditionally VIR_FREE it.  I
> fixed up storage_backend_iscsi and storage_backend_disk to reflect this change.
>  I also re-worked the code as you suggested, and added a bit more error checking.
> 

> Index: src/storage_backend.c
> ===================================================================
> RCS file: /data/cvs/libvirt/src/storage_backend.c,v
> retrieving revision 1.24
> diff -u -r1.24 storage_backend.c
> --- src/storage_backend.c	28 Oct 2008 17:48:06 -0000	1.24
> +++ src/storage_backend.c	31 Oct 2008 11:56:33 -0000
>  <at>  <at>  -357,7 +357,7  <at>  <at> 
>  char *
>  virStorageBackendStablePath(virConnectPtr conn,
>                              virStoragePoolObjPtr pool,
> -                            char *devpath)
> +                            const char *devpath)

[libvirt] New Libvirt Implementation - OpenNebula

Dear all,
        You may find of interest a new implementation of the libvirt 
virtualization API. This new implementation adds support to OpenNebula, a 
distributed VM manager system. The implementation of libvirt on top of a 
distributed VM manager, like OpenNebula, provides an abstraction of a whole 
cluster of resources (each one with its hypervisor). In this way,  you can use 
any libvirt tool (e.g. virsh, virt-manager) and XML domain descriptions at a 
distributed level. 

For example, you may create a new domain with 'virsh create', then OpenNebula 
will look for a suitable resource, transfer the VM images and boot your VM 
using any of the supported hypervisors. The distributed management is 
completely transparent to the libvirt application. This is, a whole cluster 
can be managed as any other libvirt node.

The current implementation is targeted for libvirt 0.4.4, and includes a patch 
to the libvirt source tree (mainly to modify the autotools files), and a 
libvirt driver.

More information and download instructions can be found at:

* http://trac.opennebula.org/wiki/LibvirtOpenNebula
* http://www.opennebula.org

Cheers

Ruben
--

-- 
+---------------------------------------------------------------+
 Dr. Ruben Santiago Montero

[libvirt] Does libvirt support Solaris Zones?

<div><span class="Apple-style-span">Hi!<div><br></div>
<div>I have a quick question, does libvirt latest release supports Solaris Zones? I know it supports LDoms and xVM support is being&nbsp;integrated&nbsp;towards xVM Server. But which release to date supports Solaris Zones?</div>
<div><br></div>
<div>Regards,</div>
<div>Jovial</div></span></div>

Re: [libvirt] [PATCH]: Allow arbitrary paths to virStorageVolLookupByPath

Daniel P. Berrange wrote:
>> diff -u -r1.24 storage_backend.c
>> --- src/storage_backend.c	28 Oct 2008 17:48:06 -0000	1.24
>> +++ src/storage_backend.c	31 Oct 2008 11:56:33 -0000
>>  <at>  <at>  -357,7 +357,7  <at>  <at> 
>>  char *
>>  virStorageBackendStablePath(virConnectPtr conn,
>>                              virStoragePoolObjPtr pool,
>> -                            char *devpath)
>> +                            const char *devpath)
>>  {
>>      DIR *dh;
>>      struct dirent *dent;
>>  <at>  <at>  -366,7 +366,7  <at>  <at> 
>>      if (pool->def->target.path == NULL ||
>>          STREQ(pool->def->target.path, "/dev") ||
>>          STREQ(pool->def->target.path, "/dev/"))
>> -        return devpath;
>> +        return strdup(devpath);
> 
> Need to call virStorageReportError here on OOM.
> 
>>  
>>      /* The pool is pointing somewhere like /dev/disk/by-path
>>       * or /dev/disk/by-id, so we need to check all symlinks in
>>  <at>  <at>  -410,7 +410,7  <at>  <at> 
>>      /* Couldn't find any matching stable link so give back
>>       * the original non-stable dev path
>>       */
>> -    return devpath;
>> +    return strdup(devpath);
> 
> And here.
> 
> Since virStorageBackendStablePath() api contract says that it is responsible
> for setting the errors upon failure.

Oops, of course.  I've fixed this up and committed the result; the final patch
is attached.

Thanks for the review,

-- 
Chris Lalancette

Daniel P. Berrange wrote:
>> diff -u -r1.24 storage_backend.c
>> --- src/storage_backend.c	28 Oct 2008 17:48:06 -0000	1.24
>> +++ src/storage_backend.c	31 Oct 2008 11:56:33 -0000
>>  <at>  <at>  -357,7 +357,7  <at>  <at> 
>>  char *
>>  virStorageBackendStablePath(virConnectPtr conn,
>>                              virStoragePoolObjPtr pool,
>> -                            char *devpath)
>> +                            const char *devpath)
>>  {
>>      DIR *dh;
>>      struct dirent *dent;
>>  <at>  <at>  -366,7 +366,7  <at>  <at> 
>>      if (pool->def->target.path == NULL ||
>>          STREQ(pool->def->target.path, "/dev") ||
>>          STREQ(pool->def->target.path, "/dev/"))
>> -        return devpath;
>> +        return strdup(devpath);
> 
> Need to call virStorageReportError here on OOM.
> 
>>  
>>      /* The pool is pointing somewhere like /dev/disk/by-path
>>       * or /dev/disk/by-id, so we need to check all symlinks in
>>  <at>  <at>  -410,7 +410,7  <at>  <at> 
>>      /* Couldn't find any matching stable link so give back
>>       * the original non-stable dev path
>>       */
>> -    return devpath;
>> +    return strdup(devpath);
> 
> And here.
> 
> Since virStorageBackendStablePath() api contract says that it is responsible
> for setting the errors upon failure.

Oops, of course.  I've fixed this up and committed the result; the final patch
is attached.

Thanks for the review,

--

-- 
Chris Lalancette

Re: [libvirt] Does libvirt support Solaris Zones?

On Mon, Nov 03, 2008 at 11:31:16AM +0000, jovialGuy _ wrote:
> Hi!
> I have a quick question, does libvirt latest release supports Solaris Zones?
> I know it supports LDoms and xVM support is being integrated towards xVM
> Server. But which release to date supports Solaris Zones?

Sun has a fork of a fairly old libvirt release (0.3.something IIRC) in
which they've added LDoms support. The code is not present in the 
official releases of libvirt yet, and last time I looked it didn't
really comply with the XML format correctly, and still needed quite
alot of work done to it. Hopefully they'll find the time to re-submit 
the driver for inclusion in main libvirt codebase again in  the future.

There has been work in official releases to support Xen dom0 on Open
Solaris, but I think there are still some outstanding patches in the
Open Solaris repositories that aren't in our offcial releases.

I'm not aware of any support for Solaris Zones, or xVM  -that's VirtualBox
based i guess? 

Daniel
--

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [libvirt] [PATCH 1/3]: Move argvToString to util

On Thu, Oct 30, 2008 at 02:06:06PM -0400, Cole Robinson wrote:
> The attached patch moves the argvToString function
> from iptables.c to util.c for use in later patches.

ACK

Daniel
--

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [libvirt] [PATCH 2/3]: Log argv passed to virExec and virRun

On Thu, Oct 30, 2008 at 02:06:20PM -0400, Cole Robinson wrote:
> The attached patch logs the the argv's passed to
> the virExec and virRun functions. There's a bit of
> trickery here: since virRun is just a wrapper for
> virExec, we don't want the argv string to be logged
> twice. 
> 
> I addressed this by renaming virExec to __virExec,
> and keeping the original function name to simply
> debug the argv and then hand off control. This
> means anytime virExec is explictly called, the
> argv will be logged, but if functions wish to by
> pass that they can just call __virExec (which is
> what virRun does.)

I'm a little confused about why we can't just put the logging
calling directly in the existing virExec() function. Since the
first thing virRun() does is to call virExec() this would 
seem to be sufficient without need of a wrapper.

Daniel
--

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|