Re: Request for additional entry points

On Fri, Mar 31, 2006 at 04:47:38PM -0500, Daniel Veillard wrote:
> > virDomainReboot(virDomainPtr domain)
> > Reboot the domain.
> 
> Trivial kind of cut and paste from the Shutdown routines.

I just added the following:

/**
 * virDomainReboot:
 *  <at> domain: a domain object
 *  <at> flags: extra flags for the reboot operation, not used yet
 *
 * Reboot a domain, the domain object is still usable there after but
 * the domain OS is being stopped for a restart.
 * Note that the guest OS may ignore the request.
 *
 * Returns 0 in case of success and -1 in case of failure.
 */
int
virDomainReboot(virDomainPtr domain, unsigned int flags)

there is also a new "virsh reboot" command to test it. 
However there when trying it I saw that the guest OS shutdown in reboot mode:

------------------------
Turning off quotas:
Unmounting pipe file systems:
Please stand by while rebooting the system...
md: stopping all md devices.

BUG: virDomainLookupByID fails after XenStore path discovery

I just updated to the latest CVS version of libvir.  It looks like  
there's a bug in virDomainLookupByID.  The behavior that I'm seeing  
is that the path variable is set and so the code never enters the  
block to find the value for name.  Therefore, at the end of the  
function, the condition (ret->name == NULL) is true and it jumps into  
the error code and returns NULL.

If I comment out the code that sets the path variable, things seem to  
work normally.  Although, I presume that the idea was to extract the  
name from the path information...

-bryan

-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

I just updated to the latest CVS version of libvir.  It looks like  
there's a bug in virDomainLookupByID.  The behavior that I'm seeing  
is that the path variable is set and so the code never enters the  
block to find the value for name.  Therefore, at the end of the  
function, the condition (ret->name == NULL) is true and it jumps into  
the error code and returns NULL.

If I comment out the code that sets the path variable, things seem to  

Re: BUG: virDomainLookupByID fails after XenStore path discovery

On Mon, Apr 03, 2006 at 12:01:17PM -0400, Bryan D. Payne wrote:
> I just updated to the latest CVS version of libvir.  It looks like  
> there's a bug in virDomainLookupByID.  The behavior that I'm seeing  
> is that the path variable is set and so the code never enters the  
> block to find the value for name.  Therefore, at the end of the  
> function, the condition (ret->name == NULL) is true and it jumps into  
> the error code and returns NULL.
> 
> If I comment out the code that sets the path variable, things seem to  
> work normally.  Although, I presume that the idea was to extract the  
> name from the path information...

  Right, that's a bug I introduced in the refactoring. Even if trivial
sending a small patch (cvs diff -u) is always a good idea 
Also see my next mail about servers, 

  thanks,

Daniel

--

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard <at> redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Change of server

  So far libvirt.org was hosted on my home server (IP 82.67.66.12),
but I really needed to fix this as my home ADSL connectivity isn't
that great. I moved all services to a new server (colocated on the
same box as xmlsoft.org in a public research institute here in France),
hopefully the transition to this new server (IP 194.199.20.115) will
be transparent as DNS changes propagates, but some of you mays still
access the old services for a little while.
  Tell me if you experience troubles with the new server, and if
you don't see updates from libvirt.org CVS that may be related still
using the old server. Hopefully bandwidth and relibaility should
be quite higher now,

  thanks,

Daniel

--

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard <at> redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: Request for additional entry points

On Fri, 31 Mar 2006 16:47:38 -0500, Daniel Veillard wrote:

> On Fri, Mar 31, 2006 at 10:56:06AM -0700, Jim Fehlig wrote:
>> As discussed on the xen-cim call on 3/31, the Xen CIM provider needs 
>> some additional entry points in libvirt.  I would like to open a 
>> discussion about adding the following entry points to libvirt.
>> 
>> virDomainSetConfig(virConnectPtr conn, const char *xmlDesc)
>> Stores the domU config data in xenstore.  The domU is not running yet 
>> but enumerating domains would return the config for the domain as well 
>> as any running domains.  This would support the notion of a defined but 
>> inactive virtual machine.  Daniel noted that the config could be cached 
>> in libvirt, preventing (to some degree) modifying the config out-of-band 
>> prior to activating the domain.  Note that the current 
>> virConnectListDomains() implies enumerating only running domains since a 
>> list of domain IDs is returned.  Perhaps virConnectListDomains() will 
>> have to be expanded to include defined domains or another entry point to 
>> enumerate defined domains.
> 
>   Well libvirt doesn't have the notion of 'passive' domain yet, i.e. domain
> we know exists but are not running or activated at a given point in time.
> If we define virDomainSetConfig() then we have to be able to extract at least
> the name (and uuid) from the xmlDesc. And that routine could then returm
> a virDomainPtr associated to this unactive domain (or the associated 
> active domain if it exists). Those unactive domains could then be listed
> in virConnectListDomains(). In general libvirt doesn't yet create a unique 
> proxy object per running domain, the unicity need to be garanteed, it's a TODO
> and add other constraints like reference counting and mutex when modifying
> a domain.
> 

Re: BUG: virDomainLookupByID fails after XenStore path discovery

Daniel Veillard wrote:

>On Mon, Apr 03, 2006 at 12:01:17PM -0400, Bryan D. Payne wrote:
>  
>
>>I just updated to the latest CVS version of libvir.  It looks like  
>>there's a bug in virDomainLookupByID.  The behavior that I'm seeing  
>>is that the path variable is set and so the code never enters the  
>>block to find the value for name.  Therefore, at the end of the  
>>function, the condition (ret->name == NULL) is true and it jumps into  
>>the error code and returns NULL.
>>
>>If I comment out the code that sets the path variable, things seem to  
>>work normally.  Although, I presume that the idea was to extract the  
>>name from the path information...
>>    
>>
>
>  Right, that's a bug I introduced in the refactoring. Even if trivial
>sending a small patch (cvs diff -u) is always a good idea 
>  
>

AFAIK, name is not contained in the domain's home path.  Here is a patch 
I have been using for virDomainLookupByID().

Regards,
Jim

Re: Request for additional entry points

On Fri, 2006-03-31 at 16:47 -0500, Daniel Veillard wrote:
>   Well libvirt doesn't have the notion of 'passive' domain yet, i.e. domain
> we know exists but are not running or activated at a given point in time.
> If we define virDomainSetConfig() then we have to be able to extract at least
> the name (and uuid) from the xmlDesc. And that routine could then returm
> a virDomainPtr associated to this unactive domain (or the associated 
> active domain if it exists). Those unactive domains could then be listed
> in virConnectListDomains(). 

How would that jive with other ways to create inactive domains ? Right
now I can create a file in /etc/xen and immediately have an incative
domain; I always thought that the xm scripts would eventually be
replaced by libvirt-based scripts and conventions for where to put
files, but that libvirt would remain focused on active domains.

I agree that it would be nice to have a standard way to enumerate
'defined' (as opposed to 'active') domains, but it seems a little odd to
require a library to do what amounts to putting a file into a
well-defined place.

David

Re: Request for additional entry points

On Tue, Apr 04, 2006 at 02:35:15PM -0700, David Lutterkort wrote:
> On Fri, 2006-03-31 at 16:47 -0500, Daniel Veillard wrote:
> >   Well libvirt doesn't have the notion of 'passive' domain yet, i.e. domain
> > we know exists but are not running or activated at a given point in time.
> > If we define virDomainSetConfig() then we have to be able to extract at least
> > the name (and uuid) from the xmlDesc. And that routine could then returm
> > a virDomainPtr associated to this unactive domain (or the associated 
> > active domain if it exists). Those unactive domains could then be listed
> > in virConnectListDomains(). 
> 
> How would that jive with other ways to create inactive domains ? Right
> now I can create a file in /etc/xen and immediately have an incative
> domain; I always thought that the xm scripts would eventually be
> replaced by libvirt-based scripts and conventions for where to put
> files, but that libvirt would remain focused on active domains.
> 
> I agree that it would be nice to have a standard way to enumerate
> 'defined' (as opposed to 'active') domains, but it seems a little odd to
> require a library to do what amounts to putting a file into a
> well-defined place.

 Yeah. To be honest I don't understand what is advantage of this
 solution (configs in xenstore). I think we already have in better and
 wide supported solutions how share data between more nodes (hosts). I
 don't think that we should replace OS filesystem with something like
 xenstore. I think we can implement "a standard way to enumerate
 inactive domain" without xenstore (for example by some search $PATH
 and standard FS).

    Karel

Re: BUG: virDomainLookupByID fails after XenStore path discovery

> AFAIK, name is not contained in the domain's home path.  Here is a  
> patch I have been using for virDomainLookupByID().

Actually it is...

/local/domain/≤num>/name

Cheers,
bryan

-
Bryan D. Payne
Graduate Student, Computer Science
Georgia Tech Information Security Center
http://www.bryanpayne.org

> AFAIK, name is not contained in the domain's home path.  Here is a  
> patch I have been using for virDomainLookupByID().

Actually it is...

/local/domain/≤num>/name

Cheers,
bryan

-

Re: Request for additional entry points

Daniel Veillard wrote:

>On Fri, Mar 31, 2006 at 04:47:38PM -0500, Daniel Veillard wrote:
>  
>
>I just added the following:
>
>/**
> * virDomainReboot:
> *  <at> domain: a domain object
> *  <at> flags: extra flags for the reboot operation, not used yet
> *
> * Reboot a domain, the domain object is still usable there after but
> * the domain OS is being stopped for a restart.
> * Note that the guest OS may ignore the request.
> *
> * Returns 0 in case of success and -1 in case of failure.
> */
>int
>virDomainReboot(virDomainPtr domain, unsigned int flags)
>
>there is also a new "virsh reboot" command to test it. 
>However there when trying it I saw that the guest OS shutdown in reboot mode:
>
>------------------------
>Turning off quotas:
>Unmounting pipe file systems:
>Please stand by while rebooting the system...
>md: stopping all md devices.
>md: md0 switched to read-only mode.