Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm

[Robert Middleswarth]

On 07/05/2012 04:45 PM, Adam Litke wrote:

On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote:


- Original Message -

From: "Adam Litke" 
To: "Saggi Mizrahi" 
Cc: "Anthony Liguori" , "VDSM Project Development" 

Sent: Thursday, July 5, 2012 2:34:50 PM
Subject: Re: [RFC] An alternative way to provide a supported interface -- 
libvdsm

On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:

The idea of having a supported C API was something I was thinking
about doing
(But I'd rather use gobject introspection and not schema
generation) But the
problem is not having a C API is using the current XML RPC API as
it's base

I want to disect this a bit to find out exactly where there might be
agreement
and disagreement.

C API is a good thing to implement - Agreed.

I also want to use gobject introspection but I don't agree that using
glib
precludes the use of a formalized schema.  My proposal is that we
write a schema
definition and generate the glib C code from that schema.

I agree that the _current_ xmlrpc API makes a pretty bad base from
which to
start a supportable API.  XMLRPC is a perfectly reasonable
remote/wire protocol
and I think we should continue using it as a base for the next
generation API.
Using a schema will ensure that the new API is well-structured.

There major problems with XML-RPC (and to some extent with REST as well) are 
high call overhead and no two way communication (push events). Basing on 
XML-RPC means that we will never be able to solve these issues.

I am not sure I am ready to conceed that XML-RPC is too slow for our needs.  Can
you provide some more detail around this point and possibly suggest an
alternative that has even lower overhead without sacrificing the ubiquity and
usability of XML-RPC?  As far as the two-way communication point, what are the
options besides AMQP/ZeroMQ?  Aren't these even worse from an overhead
perspective than XML-RPC?  Regarding two-way communication: you can write AMQP
brokers based on the C API and run one on each vdsm host.  Assuming the C API
supports events, what else would you need?
I personally think that using something like AMQP for inter-node 
communication and engine - node would be optimal.  With a rest interface 
that just send messages though something like AMQP.


Thanks
Robert

The current XML-RPC API contains a lot of decencies and
inefficiencies and we
would like to retire it as soon as we possibly can. Engine would
like us to
move to a message based API and 3rd parties want something simple
like REST so
it looks like no one actually wants to use XML-RPC. Not even us.

I am proposing that AMQP brokers and REST APIs could be written
against the
public API.  In fact, they need not even live in the vdsm tree
anymore if that
is what we choose.  Core vdsm would only be responsible for providing
libvdsm
and whatever language bindings we want to support.

If we take the libvdsm route, the only reason to even have a REST bridge is 
only to support OSes other then Linux which is something I'm not sure we care 
about at the moment.

That might be true regarding the current in-tree implementation.  However, I can
almost guarantee that someone wanting to write a web GUI on top of standalone
vdsm would want a REST API to talk to.  But libvdsm makes this use case of no
concern to the core vdsm developers.


I do think that having C supportability in our API is a good idea,
but the
current API should not be used as the base.

Let's _start_ with a schema document that describes today's API and
then clean
it up.  I think that will work better than starting from scratch.
  Once my
schema is written I will post it and we can 'patch' it as a community
until we
arrive at a 1.0 version we are all happy with.

+1

Ok.  Redoubling my efforts to get this done.  Describing the output of
list(True) takes awhile :)




___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm

[Saggi Mizrahi]

- Original Message -
> From: "Adam Litke" 
> To: "Saggi Mizrahi" 
> Cc: "Anthony Liguori" , "VDSM Project Development" 
> 
> Sent: Thursday, July 5, 2012 4:45:08 PM
> Subject: Re: [RFC] An alternative way to provide a supported interface -- 
> libvdsm
> 
> On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote:
> > 
> > 
> > - Original Message -
> > > From: "Adam Litke" 
> > > To: "Saggi Mizrahi" 
> > > Cc: "Anthony Liguori" , "VDSM Project
> > > Development" 
> > > Sent: Thursday, July 5, 2012 2:34:50 PM
> > > Subject: Re: [RFC] An alternative way to provide a supported
> > > interface -- libvdsm
> > > 
> > > On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
> > > > The idea of having a supported C API was something I was
> > > > thinking
> > > > about doing
> > > > (But I'd rather use gobject introspection and not schema
> > > > generation) But the
> > > > problem is not having a C API is using the current XML RPC API
> > > > as
> > > > it's base
> > > 
> > > I want to disect this a bit to find out exactly where there might
> > > be
> > > agreement
> > > and disagreement.
> > > 
> > > C API is a good thing to implement - Agreed.
> > > 
> > > I also want to use gobject introspection but I don't agree that
> > > using
> > > glib
> > > precludes the use of a formalized schema.  My proposal is that we
> > > write a schema
> > > definition and generate the glib C code from that schema.
> > > 
> > > I agree that the _current_ xmlrpc API makes a pretty bad base
> > > from
> > > which to
> > > start a supportable API.  XMLRPC is a perfectly reasonable
> > > remote/wire protocol
> > > and I think we should continue using it as a base for the next
> > > generation API.
> > > Using a schema will ensure that the new API is well-structured.
> > There major problems with XML-RPC (and to some extent with REST as
> > well) are high call overhead and no two way communication (push
> > events). Basing on XML-RPC means that we will never be able to
> > solve these issues.
> 
> I am not sure I am ready to conceed that XML-RPC is too slow for our
> needs.  Can
> you provide some more detail around this point and possibly suggest
> an
> alternative that has even lower overhead without sacrificing the
> ubiquity and
> usability of XML-RPC?  As far as the two-way communication point,
> what are the
> options besides AMQP/ZeroMQ?  Aren't these even worse from an
> overhead
> perspective than XML-RPC?  Regarding two-way communication: you can
> write AMQP
> brokers based on the C API and run one on each vdsm host.  Assuming
> the C API
> supports events, what else would you need?
If we plan to go with the libvdsm route the only transports I think are 
appropriate are either raw sockets (like libvirt) or ZMQ (just to take 
advantage of it managing connection and message encapsulation but it might be 
an overkill). Other then that ZMQ\AMQP\REST\XML-RPC bridges are not really a 
priority for me as engine will not be using any of the bridges.
> 
> > > > The current XML-RPC API contains a lot of decencies and
> > > > inefficiencies and we
> > > > would like to retire it as soon as we possibly can. Engine
> > > > would
> > > > like us to
> > > > move to a message based API and 3rd parties want something
> > > > simple
> > > > like REST so
> > > > it looks like no one actually wants to use XML-RPC. Not even
> > > > us.
> > > 
> > > I am proposing that AMQP brokers and REST APIs could be written
> > > against the
> > > public API.  In fact, they need not even live in the vdsm tree
> > > anymore if that
> > > is what we choose.  Core vdsm would only be responsible for
> > > providing
> > > libvdsm
> > > and whatever language bindings we want to support.
> > If we take the libvdsm route, the only reason to even have a REST
> > bridge is only to support OSes other then Linux which is something
> > I'm not sure we care about at the moment.
> 
> That might be true regarding the current in-tree implementation.
>  However, I can
> almost guarantee that someone wanting to write a web GUI on top of
> standalone
> vdsm would want a REST API to talk to.  But libvdsm makes this use
> case of no
> concern to the core vdsm developers.
> 
> > > > I do think that having C supportability in our API is a good
> > > > idea,
> > > > but the
> > > > current API should not be used as the base.
> > > 
> > > Let's _start_ with a schema document that describes today's API
> > > and
> > > then clean
> > > it up.  I think that will work better than starting from scratch.
> > >  Once my
> > > schema is written I will post it and we can 'patch' it as a
> > > community
> > > until we
> > > arrive at a 1.0 version we are all happy with.
> > +1
> 
> Ok.  Redoubling my efforts to get this done.  Describing the output
> of
> list(True) takes awhile :)
> 
> --
> Adam Litke 
> IBM Linux Technology Center
> 
> 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.

Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm

[Adam Litke]

On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote:
> 
> 
> - Original Message -
> > From: "Adam Litke" 
> > To: "Saggi Mizrahi" 
> > Cc: "Anthony Liguori" , "VDSM Project Development" 
> > 
> > Sent: Thursday, July 5, 2012 2:34:50 PM
> > Subject: Re: [RFC] An alternative way to provide a supported interface -- 
> > libvdsm
> > 
> > On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
> > > The idea of having a supported C API was something I was thinking
> > > about doing
> > > (But I'd rather use gobject introspection and not schema
> > > generation) But the
> > > problem is not having a C API is using the current XML RPC API as
> > > it's base
> > 
> > I want to disect this a bit to find out exactly where there might be
> > agreement
> > and disagreement.
> > 
> > C API is a good thing to implement - Agreed.
> > 
> > I also want to use gobject introspection but I don't agree that using
> > glib
> > precludes the use of a formalized schema.  My proposal is that we
> > write a schema
> > definition and generate the glib C code from that schema.
> > 
> > I agree that the _current_ xmlrpc API makes a pretty bad base from
> > which to
> > start a supportable API.  XMLRPC is a perfectly reasonable
> > remote/wire protocol
> > and I think we should continue using it as a base for the next
> > generation API.
> > Using a schema will ensure that the new API is well-structured.
> There major problems with XML-RPC (and to some extent with REST as well) are 
> high call overhead and no two way communication (push events). Basing on 
> XML-RPC means that we will never be able to solve these issues.

I am not sure I am ready to conceed that XML-RPC is too slow for our needs.  Can
you provide some more detail around this point and possibly suggest an
alternative that has even lower overhead without sacrificing the ubiquity and
usability of XML-RPC?  As far as the two-way communication point, what are the
options besides AMQP/ZeroMQ?  Aren't these even worse from an overhead
perspective than XML-RPC?  Regarding two-way communication: you can write AMQP
brokers based on the C API and run one on each vdsm host.  Assuming the C API
supports events, what else would you need?

> > > The current XML-RPC API contains a lot of decencies and
> > > inefficiencies and we
> > > would like to retire it as soon as we possibly can. Engine would
> > > like us to
> > > move to a message based API and 3rd parties want something simple
> > > like REST so
> > > it looks like no one actually wants to use XML-RPC. Not even us.
> > 
> > I am proposing that AMQP brokers and REST APIs could be written
> > against the
> > public API.  In fact, they need not even live in the vdsm tree
> > anymore if that
> > is what we choose.  Core vdsm would only be responsible for providing
> > libvdsm
> > and whatever language bindings we want to support.
> If we take the libvdsm route, the only reason to even have a REST bridge is 
> only to support OSes other then Linux which is something I'm not sure we care 
> about at the moment.

That might be true regarding the current in-tree implementation.  However, I can
almost guarantee that someone wanting to write a web GUI on top of standalone
vdsm would want a REST API to talk to.  But libvdsm makes this use case of no
concern to the core vdsm developers.

> > > I do think that having C supportability in our API is a good idea,
> > > but the
> > > current API should not be used as the base.
> > 
> > Let's _start_ with a schema document that describes today's API and
> > then clean
> > it up.  I think that will work better than starting from scratch.
> >  Once my
> > schema is written I will post it and we can 'patch' it as a community
> > until we
> > arrive at a 1.0 version we are all happy with.
> +1

Ok.  Redoubling my efforts to get this done.  Describing the output of
list(True) takes awhile :)

-- 
Adam Litke 
IBM Linux Technology Center

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm

[Saggi Mizrahi]

- Original Message -
> From: "Adam Litke" 
> To: "Saggi Mizrahi" 
> Cc: "Anthony Liguori" , "VDSM Project Development" 
> 
> Sent: Thursday, July 5, 2012 2:34:50 PM
> Subject: Re: [RFC] An alternative way to provide a supported interface -- 
> libvdsm
> 
> On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
> > The idea of having a supported C API was something I was thinking
> > about doing
> > (But I'd rather use gobject introspection and not schema
> > generation) But the
> > problem is not having a C API is using the current XML RPC API as
> > it's base
> 
> I want to disect this a bit to find out exactly where there might be
> agreement
> and disagreement.
> 
> C API is a good thing to implement - Agreed.
> 
> I also want to use gobject introspection but I don't agree that using
> glib
> precludes the use of a formalized schema.  My proposal is that we
> write a schema
> definition and generate the glib C code from that schema.
> 
> I agree that the _current_ xmlrpc API makes a pretty bad base from
> which to
> start a supportable API.  XMLRPC is a perfectly reasonable
> remote/wire protocol
> and I think we should continue using it as a base for the next
> generation API.
> Using a schema will ensure that the new API is well-structured.
There major problems with XML-RPC (and to some extent with REST as well) are 
high call overhead and no two way communication (push events). Basing on 
XML-RPC means that we will never be able to solve these issues.

>  
> > The current XML-RPC API contains a lot of decencies and
> > inefficiencies and we
> > would like to retire it as soon as we possibly can. Engine would
> > like us to
> > move to a message based API and 3rd parties want something simple
> > like REST so
> > it looks like no one actually wants to use XML-RPC. Not even us.
> 
> I am proposing that AMQP brokers and REST APIs could be written
> against the
> public API.  In fact, they need not even live in the vdsm tree
> anymore if that
> is what we choose.  Core vdsm would only be responsible for providing
> libvdsm
> and whatever language bindings we want to support.
If we take the libvdsm route, the only reason to even have a REST bridge is 
only to support OSes other then Linux which is something I'm not sure we care 
about at the moment.

> 
> > I do think that having C supportability in our API is a good idea,
> > but the
> > current API should not be used as the base.
> 
> Let's _start_ with a schema document that describes today's API and
> then clean
> it up.  I think that will work better than starting from scratch.
>  Once my
> schema is written I will post it and we can 'patch' it as a community
> until we
> arrive at a 1.0 version we are all happy with.
+1
> 
> If we are going to break compatibility with the current xmlrpc
> interface, I
> would like to have a commitment from ovirt-engine to support the new
> library
> interface so that we can drop xmlrpc.
> 
> --
> Adam Litke 
> IBM Linux Technology Center
> 
> 
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm

[Adam Litke]

On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote:
> The idea of having a supported C API was something I was thinking about doing
> (But I'd rather use gobject introspection and not schema generation) But the
> problem is not having a C API is using the current XML RPC API as it's base

I want to disect this a bit to find out exactly where there might be agreement
and disagreement.

C API is a good thing to implement - Agreed.

I also want to use gobject introspection but I don't agree that using glib
precludes the use of a formalized schema.  My proposal is that we write a schema
definition and generate the glib C code from that schema.

I agree that the _current_ xmlrpc API makes a pretty bad base from which to
start a supportable API.  XMLRPC is a perfectly reasonable remote/wire protocol
and I think we should continue using it as a base for the next generation API.
Using a schema will ensure that the new API is well-structured.
 
> The current XML-RPC API contains a lot of decencies and inefficiencies and we
> would like to retire it as soon as we possibly can. Engine would like us to
> move to a message based API and 3rd parties want something simple like REST so
> it looks like no one actually wants to use XML-RPC. Not even us.

I am proposing that AMQP brokers and REST APIs could be written against the
public API.  In fact, they need not even live in the vdsm tree anymore if that
is what we choose.  Core vdsm would only be responsible for providing libvdsm
and whatever language bindings we want to support.

> I do think that having C supportability in our API is a good idea, but the
> current API should not be used as the base.

Let's _start_ with a schema document that describes today's API and then clean
it up.  I think that will work better than starting from scratch.  Once my
schema is written I will post it and we can 'patch' it as a community until we
arrive at a 1.0 version we are all happy with.

If we are going to break compatibility with the current xmlrpc interface, I
would like to have a commitment from ovirt-engine to support the new library
interface so that we can drop xmlrpc.

--
Adam Litke 
IBM Linux Technology Center

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Readonly leases error in vdsm log

[Shu Ming]

On 2012-7-5 20:12, Deepak C Shetty wrote:


It looks like its trying to use the cdrom disk device as a disk lea


It seems this bug was hit:

*Bug 828633*  
-Sanlock locking failed for readonly devices

https://bugzilla.redhat.com/show_bug.cgi?id=828633

--
Shu Ming 
IBM China Systems and Technology Laboratory

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

[vdsm] Readonly leases error in vdsm log

[Deepak C Shetty]

Hello,
I am creating a VM using vdsm standalone script and facing issues 
when i add cdrom and make it boot from cdrom.




vdsOK(
s.create(dict(vmId=vmId,
  drives=[dict(poolID=spUUID, domainID=sdUUID, 
imageID=imgUUID, volumeID=volUUID)],

  memSize=256,
  display="vnc",
  vmName="vm-backed-by-gluster",
  cdrom="/home/deepakcs/Fedora-16-x86_64-Live-Desktop.iso",
  boot="d",
  custom={"dpktry":1},
 )
)

When i added cdrom= and boot= lines and ran, i see the below in vdsm.log

Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm
self._run()
  File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run
self._connection.createXML(domxml, flags),
  File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", 
line 82, in wrapper

ret = f(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2420, in 
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', 
conn=self)
libvirtError: internal error unsupported configuration: Readonly leases 
are not supported
Thread-49::DEBUG::2012-07-05 
17:35:59,780::vm::920::vm.Vm::(setDownStatus) 
vmId=`8b400342-2cda-478d-93f6-a36bac8538c8`::Changed state to Down: 
internal error unsupported configuration: Readonly leases are not supported



It looks like its trying to use the cdrom disk device as a disk lease, 
hence complaining?

But the libvirt xml has  tags which looks liek this...


file="/rhev/data-center/98fc6cd9-d857-4735-bc7a-59a289bc0f55/01400276-e3c8-44d9-8353-924ab2183af2/images/95c9f6a4-def1-4300-baf6-db884dc8ccca/9d62e802-859e-4381-8029-7be5a6b1de26"/>


95c9f6a4-def1-4300-baf6-db884dc8ccca
type="raw"/>



startupPolicy="optional"/>





Any idea why it throws "Readonly leases are not supported" ?

thanx,
deepak

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Agenda for today's call

[Dan Kenigsberg]

On Thu, Jul 05, 2012 at 04:49:21PM +0530, Deepak C Shetty wrote:
> On 07/02/2012 07:26 PM, Dan Kenigsberg wrote:
> >On Mon, Jul 02, 2012 at 12:32:10PM +0300, Deepak C Shetty wrote:
> >>Stuff I'd like to mention today:
> >Call quorum unsatisfied: only Saggi, Tony and myself called in.
> >We discussed Saggi's plans for a new API for Vdsm, and aboout Tony's
> >progress with libstorage (and targetd thereof).
> 
> I was out sick, hence couldn't attend the call.
> Any minutes posted or someone can post here pls ?

Nope. No quorum, no meeting.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Re: [vdsm] Using vdsm hook to exploit gluster backend of qemu

[Deepak C Shetty]

Hello All,
Any updates/comments on this mail, anybody ?

More comments/questions inline below
'would appreciate response which can help me here.

thanx,
deepak

On 06/27/2012 06:44 PM, Deepak C Shetty wrote:

Hello,
Recently there were patches posted in qemu-devel to support 
gluster as a block backend for qemu.


This introduced new way of specifying drive location to qemu as ...
-drive file=gluster::

where...
volumefile is the gluster volume file name ( say gluster volume is 
pre-configured on the host )

image name is the name of the image file on the gluster mount point

I wrote a vdsm standalone script using SHAREDFS ( which maps to 
PosixFs ) taking cues from http://www.ovirt.org/wiki/Vdsm_Standalone

The conndict passed to connectStorageServer is as below...
[dict(id=1, connection="kvmfs01-hs22:dpkvol", vfs_type="glusterfs", 
mnt_options="")]


Here note that 'dpkvol' is the name of the gluster volume

I and am able to create and invoke a VM backed by a image file 
residing on gluster mount.


But since this is SHAREDFS way, the qemu -drive cmdline generated via 
VDSM is ...
-drive file=/rhev/datacentre/mnt/ -- which eventually softlinks to 
the image file on the gluster mount point.


I was looking to write a vdsm hook to be able to change the above to 
-drive file=gluster::

which means I would need access to some of the conndict params inside 
the hook, esp. the 'connection' to extract the volume name.


1) In looking at the current VDSM code, i don't see a way for the hook 
to know anything abt the storage domain setup. So the only
way is to have the user pass a custom param which provides the path to 
the volumefile & image and use it in the hook. Is there
a better way ? Can i use the vdsm gluster plugin support inside the 
hook to determine the volfile from the volname, assuming I
only take the volname as the custom param, and determine imagename 
from the existing  tag ( basename is the
image name). Wouldn't it be better to provide a way for hooks to 
access ( readonly) storage domain parameters, so that they can

use that do implement the hook logic in a more saner way ?

2) In talking to Eduardo, it seems there are discussion going on to 
see how prepareVolumePath and prepareImage could be exploited
to fit gluster ( and in future other types) based images. I am not 
very clear on the image and volume code of vdsm, frankly its very

complex and hard to understand due to lack of comments.

I would appreciate if someone can guide me on what is the best way to 
achive my goal (-drive file=gluster::)
here. Any short term solutions if not perfect solution are also 
appreciated, so that I can atleast have a working setup where I just
run my VDSM standaloen script and my qemu cmdline using gluster:... is 
generated.


Currently I am using  tag facility of libvirt to 
inject the needed qemu options and hardcoding the volname, imagename
but i would like to do this based on the conndict passed by the user 
when creating SHAREDFS domain.




I am using VDSM hook to customise the  libvirt xml to add -drive 
file=gluster: cmdline option, but facing issues as below...
NOTE: I am using the libvirt's generic qemu:commandline tag facility to 
add my needed qemu options.


1) I replace the existing  tag with my new qemu:commandline tag to 
introduce -drive file=gluster:


This is what i add in my vdsm hook...


value="file=gluster:/var/lib/glusterd/vols/dpkvol/dpkvol-qemu.vol:/d536ca42-9dd2-40a2-bd45-7e5c67751698/images/e9d31bc2-9fb6-4803-aa88-5563229aad41/1c3463aa-be2c-4405--7283b166e981,format=gluster"/>



In this case the qemu process is created ( as seen from ps aux) but the 
VM is in stopped state, vdsm does not start it, and using virsh i 
cannot, it says 'unable to acquire some lock"

There is no way i can force start it from the vdscli cmdline too.
From the vdsm.log all i can see is till the point vdsm dumps the 
libvirt xml... then nothing happens.


In other cases ( when i am not using this custom cmdline and the 
standard  tag is present ).. i see the below msgs in vdsm.log 
after it dumps libvirt xml...


libvirtEventLoop::DEBUG::2012-07-05 
13:52:17,780::libvirtvm::2409::vm.Vm::(_onLibvirtLifecycleEvent) 
vmId=`1eb2b3f7-a319-44fe-8263-fd6e770db983`::event Started detail 0 
opaque None
Thread-49::DEBUG::2012-07-05 13:52:17,819::utils::329::vm.Vm::(start) 
vmId=`1eb2b3f7-a319-44fe-8263-fd6e770db983`::Start statistics collection
Thread-51::DEBUG::2012-07-05 13:52:17,819::utils::358::vm.Vm::(run) 
vmId=`1eb2b3f7-a319-44fe-8263-fd6e770db983`::Stats thread started
Thread-51::DEBUG::2012-07-05 
13:52:17,821::task::588::TaskManager.Task::(_updateState) 
Task=`f66ac43a-1528-491c-bdee-37112dac536c`::moving from state init -> 
state preparing
Thread-51::INFO::2012-07-05 
13:52:17,822::logUtils::37::dispatcher::(wrapper) Run and protect: 
getVolumeSize(sdUUID='a75b80f8-eb6d-4a01-b57c-66d62db2d867', 
spUUID='763d7ee5-de1e-4cd3-8af8-654865b2476d', 
imgUUID='579567

Re: [vdsm] Agenda for today's call

[Deepak C Shetty]

On 07/02/2012 07:26 PM, Dan Kenigsberg wrote:

On Mon, Jul 02, 2012 at 12:32:10PM +0300, Deepak C Shetty wrote:

Stuff I'd like to mention today:

Call quorum unsatisfied: only Saggi, Tony and myself called in.
We discussed Saggi's plans for a new API for Vdsm, and aboout Tony's
progress with libstorage (and targetd thereof).


I was out sick, hence couldn't attend the call.
Any minutes posted or someone can post here pls ?

___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel