Mailing List Archive

legacy vbds and new vdis
While moving the cim providers forward on new Xen API functionality I
come across a problem retrieving the uname information of a vbd. If vbd
is created via Xen API, a vdi had to be created first and is
subsequently retrievable via vdi field of vbd record. However, if a vm
is 'xm newed' or 'xm created' using a traditional conf file, vdis are
not created and hence not accessible via the vdi field of vbd. So there
is no way to retrieve (via Xen API) the uname of device backing the vbd.

I'm considering a patch that creates a 'default' vdi for each vbd when
vms are created outside of Xen API, but not convinced this is the proper
solution. Suggestions before creating such a patch?

Regards,
Jim

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: legacy vbds and new vdis [ In reply to ]
If you use the new xm which creates stuff via the XenAPI, then a vdi
is created. If you look at tools/python/xen/xm/xenapi_create.py
theres code that basically already does this, but in xm.

If you want to put this into xend for the old api, then I think that
would be fine, but we're going to deprecate and eventually remove the
old SXP based interface.

Hope this helps

Tom

On 9 May 2007, at 01:00, Jim Fehlig wrote:

> While moving the cim providers forward on new Xen API functionality I
> come across a problem retrieving the uname information of a vbd.
> If vbd
> is created via Xen API, a vdi had to be created first and is
> subsequently retrievable via vdi field of vbd record. However, if
> a vm
> is 'xm newed' or 'xm created' using a traditional conf file, vdis are
> not created and hence not accessible via the vdi field of vbd. So
> there
> is no way to retrieve (via Xen API) the uname of device backing the
> vbd.
>
> I'm considering a patch that creates a 'default' vdi for each vbd when
> vms are created outside of Xen API, but not convinced this is the
> proper
> solution. Suggestions before creating such a patch?
>
> Regards,
> Jim
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api


_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: legacy vbds and new vdis [ In reply to ]
Tom Wilkie wrote:
> If you use the new xm which creates stuff via the XenAPI, then a vdi
> is created. If you look at tools/python/xen/xm/xenapi_create.py
> theres code that basically already does this, but in xm.

Right, I have vdis created when xm is using XenAPI. However xm does not
use XenAPI by default.

> If you want to put this into xend for the old api, then I think that
> would be fine, but we're going to deprecate and eventually remove the
> old SXP based interface.

Hmm... Don't know if I want to waste time creating a patch that will be
short-lived. Are there any reasons not to have xm using XenAPI? I.e.
what issues might I encounter if I put the following in xm-config.xml
and xend-config.sxp respectively?

<xm>
<server type='Xen-API'
uri='httpu:///var/run/xend/xen-api.sock' />
</xm>

(xen-api-server ((unix none)))

I have not encountered any issues (yet) running with this configuration,
but have only used a fraction of available commands.

Regards,
Jim


_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
Re: legacy vbds and new vdis [ In reply to ]
On Wed, May 09, 2007 at 03:12:33PM -0600, Jim Fehlig wrote:

> Tom Wilkie wrote:
> > If you use the new xm which creates stuff via the XenAPI, then a vdi
> > is created. If you look at tools/python/xen/xm/xenapi_create.py
> > theres code that basically already does this, but in xm.
>
> Right, I have vdis created when xm is using XenAPI. However xm does not
> use XenAPI by default.
>
> > If you want to put this into xend for the old api, then I think that
> > would be fine, but we're going to deprecate and eventually remove the
> > old SXP based interface.
>
> Hmm... Don't know if I want to waste time creating a patch that will be
> short-lived. Are there any reasons not to have xm using XenAPI? I.e.
> what issues might I encounter if I put the following in xm-config.xml
> and xend-config.sxp respectively?
>
> <xm>
> <server type='Xen-API'
> uri='httpu:///var/run/xend/xen-api.sock' />
> </xm>
>
> (xen-api-server ((unix none)))
>
> I have not encountered any issues (yet) running with this configuration,
> but have only used a fraction of available commands.

It didn't get turned on by default simply because it hasn't had enough
testing, so we're not sure that we've got full coverage for all the old
functionality. The great majority of stuff certainly works, and we'll be
turning it on once the unstable tree opens for business again, so that we can
get it more widely tested. It will be the default in the next release.

Ewan.

_______________________________________________
xen-api mailing list
xen-api@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api