Re: [PATCH] lxc: start domain

Daniel Veillard wrote:
>>> [...]
>>>
>>>   Hum, now that config names are saved based on domain names, wouldn't
>>> it be better to use a name based lookup ? Less precise but more direct
>> Not sure what you're referring to here.  name based lookup for what?
> 
>   Hum, wrong part quoted, it's about lxcDomainStart() just below:
> 
> :+static int lxcDomainStart(virDomainPtr dom)
> :+{
> :+    int rc = -1;
> :+    virConnectPtr conn = dom->conn;
> :+    lxc_driver_t *driver = (lxc_driver_t *)(conn->privateData);
> :+    lxc_vm_t *vm = lxcFindVMByUUID(driver, dom->uuid);
> :+
>

Ah, ok.  Yep, I can change that...

--

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

Re: uuid of newly created domain

On Mon, Mar 31, 2008 at 03:53:09PM -0700, Vadim Zaliva wrote:
> On Mar 31, 2008, at 11:40, Vadim Zaliva wrote:
> >I am trying to track down the problem.
> 
> 
> OK, I have been able to reproduce the problem, is C, without Ruby.  
> Attached is source code
> and XML file. Here is a sample output:
> 
> Attempt 0:
> define
> Domain defined with UUID 714b96db-a6b4-a4ea-ad58-39e4b44575c0
> lookup by UUID 714b96db-a6b4-a4ea-ad58-39e4b44575c0
> Lookup found domain with UUID 714b96db-a6b4-a4ea-ad58-39e4b44575c0
> undefine
> 
> Attempt 1:
> define
> Domain defined with UUID 714b96db-a6b4-a4ea-ad58-39e4b44575c0
> lookup by UUID 714b96db-a6b4-a4ea-ad58-39e4b44575c0
> libvir: Xen Daemon error : GET operation failed:
> Failed to lookup by UUID string domain
> 
> As you can see, it works OK first time, but the second time, returns  
> the same UUID, lookup on which fails.

The problem is that you are not freeing the virDomainPtr object
after you undefine the first VM. Libvirt caches virDomainPtr objects
based on the 'name' value. So the second time around you are getting
the cached handle. You are also leaking memory.

Re: uuid of newly created domain

On Mar 31, 2008, at 16:28, Daniel P. Berrange wrote:
> The problem is that you are not freeing the virDomainPtr object
> after you undefine the first VM. Libvirt caches virDomainPtr objects
> based on the 'name' value. So the second time around you are getting
> the cached handle. You are also leaking memory.
>
> You need to call
>
>  virDomainFree(virDomainPtr dom)
>
> to actually release the handle.

Thanks for the explanation. I will try this in my code.

However, I think this behavior is counter-intuitive. I was expecting  
that undefining
domain should remove it from cache, or creating new domain with same  
name should replace
old definition with a new one.

Sincerely,
Vadim

--
"La perfection est atteinte non quand il ne reste rien a ajouter, mais
quand il ne reste rien a enlever."  (Antoine de Saint-Exupery)

Re: uuid of newly created domain

On Mar 31, 2008, at 16:28, Daniel P. Berrange wrote:
> The problem is that you are not freeing the virDomainPtr object
> after you undefine the first VM. Libvirt caches virDomainPtr objects
> based on the 'name' value. So the second time around you are getting
> the cached handle. You are also leaking memory.
>
> You need to call
>
>  virDomainFree(virDomainPtr dom)
>
> to actually release the handle.

I could not figure out how this could be expressed via Ruby bindings.  
This function is called when object is freed, but when it happens is  
controlled by GC.

For example, KDE Ruby binding are using dispose() method paradigm to  
solve this kind of problem:

http://developer.kde.org/language-bindings/ruby/

Should we add one to Domain class?

Sincerely,
Vadim

P.S. I think the Python bindings have the same problem, virDomainPtr()  
is called from __del__() there.

--

Re: Re: Lxc conf patch

On Mon, Mar 31, 2008 at 03:24:22PM -0700, Dave Leskovec wrote:
> Meant to include this in the last reply - Here's a patch for the lxcFreeVMs() issue:
> 
> > 
> > This breaks doesn't it?  After calling lxcFreeVM(), curVm is no longer valid
> > since it was free()'d.  Need to pull out the next pointer before lxcFreeVM().

  yup, obviously access to freed memory, my bad ...

>      while (curVm) {
> -        lxcFreeVM(curVm);
>          nextVm = curVm->next;
> +        lxcFreeVM(curVm);
>          curVm = nextVm;

  Applied and commited, 

    thanks !

Daniel

--

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

patch: Domain.free() in Ruby bindings

Attached patch adds new method free() to Domain class. Invocation of  
this method
calls virDomainFree(). After this call, all other calls to this domain  
object would
fail.

The purpose of this patch is to solve problem caused by libvirt  
caching, when creation
of new domain from XML is re-using previous definition with the same  
name, if domain
object associated with older definition have not been yet freed by  
Ruby garbage collector
(see previous discussion in this mailing list for details).

Sincerely,
Vadim Zaliva

P.S. I think Python bindings will need similar method as well.

P.P.S. I have tested this patch, and I can see that it solves the  
problem I was facing.

Attached patch adds new method free() to Domain class. Invocation of  
this method
calls virDomainFree(). After this call, all other calls to this domain  
object would

Re: patch: Domain.free() in Ruby bindings

On Tue, 2008-04-01 at 10:04 -0700, Vadim Zaliva wrote:
> Attached patch adds new method free() to Domain class. Invocation of  
> this method
> calls virDomainFree(). After this call, all other calls to this domain  
> object would
> fail.

Thanks for the patch. I just committed a slight variation of the patch -
for symmetry, I added free methods for Network, StorageVol and
StoragePool, too.

David

[PATCH] [RUBY-LIBVIRT]: Make the flags parameter optional

All,
     While using the ruby-libvirt bindings, I usually end up setting the "flags"
parameter to various calls to 0.  While this is required by the C side of
things, for Ruby we have no such constraint; we can have methods with optional
arguments.  Since most of the time we will be passing "flags" as 0, we will just
assume 0 if it isn't specified, and actually use the value in flags if it is.
The attached patch does just that.  Note that I've only tested about half of the
calls in here; further breakage should be easy to find and fix.  Also note that
this should not impact existing users, since we will honor the flags they are
already passing.

Signed-off-by: Chris Lalancette <clalance <at> redhat.com>

All,
     While using the ruby-libvirt bindings, I usually end up setting the "flags"
parameter to various calls to 0.  While this is required by the C side of
things, for Ruby we have no such constraint; we can have methods with optional
arguments.  Since most of the time we will be passing "flags" as 0, we will just
assume 0 if it isn't specified, and actually use the value in flags if it is.
The attached patch does just that.  Note that I've only tested about half of the
calls in here; further breakage should be easy to find and fix.  Also note that
this should not impact existing users, since we will honor the flags they are
already passing.

Signed-off-by: Chris Lalancette <clalance <at> redhat.com>

Proposal for dealing with host devices

The following document illustrates an API for host device enumeration,
creation and deletion. This has a number of use cases:

 - PCI passthrough. Need to enumerate PCI devices, get their domain,
   bus, slot, function IDs to be able to pass-though to a guest.
   Need to disable the host kernel driver. Need to get metadata about
   the device to present to the user, eg model / vendor.

 - USB passthrough. Need to enumerate USB devices, get their bus, device
   IDs to be able to pass-though to a guest. Need to disable the host
   kernel driver. Need to get metadata about the device to present to
   the user, eg model / vendor.

 - Fibre Channel. Need to enumerate SCSI HBAs with FC capability and
   get their WWNN and WWPN (World Wide Node/Port Name) to enable the
   administrator to associate with the SAN.
   This relates to the SCSI storage pool impl I posted last week

 - NPIV. Need to create/delete NPIV virtual Fibre Channel adapters.
   This relates to the SCSI storage pool impl I posted last week

 - Networking. Need to enumerate NICs, bridges, VLANs, bonding.

This all sounds like alot of data / stuff to manage, but the good news
is that there is already an application which does most of this for
us. ie HAL.  So at the basic level all we need to do is map the HAL
properties into a libvirt XML format for describing devices.

I have chosen to define a very direct mapping.

Re: Proposal for dealing with host devices

On Wed, Apr 02, 2008 at 02:05:58AM +0100, Daniel P. Berrange wrote:
> 
> The following document illustrates an API for host device enumeration,
> creation and deletion. This has a number of use cases:
[...]
> This all sounds like alot of data / stuff to manage, but the good news
> is that there is already an application which does most of this for
> us. ie HAL.  So at the basic level all we need to do is map the HAL
> properties into a libvirt XML format for describing devices.

  Having gone though the description a couple of time, this makes sense
to me I just have a couple of remarks:
   - basically we are now extending libvirt to be a generic accessor
     for host physical data it's fine because we need it but ...
   - if hald daemons (I have 5 hal related daemons running mon my F8 
     desktops) had exported things in a secure way most of this would not
     be needed, right ?

But having a remote secure way to access hardware data is needed, if libvirt
is the first one to provide it, why not ! It will certainly make things
easier for libvirt users.

> I have chosen to define a very direct mapping.

 Agreed, no need to remap, basically the only thing really hal specific
in the exposed XML data are the hal names, which are basically internal
unique names for addressing the devices, and public names usable for
user comminication are also available so that's fine.

[...]