9:38 a.m.
There's already one for saving live domains:
int virDomainSave(virDomainPtr domain, const char *to);
Why not use a similar API for a function which does the equivalent of
'xm dump' ?
int virDomainDump(virDomainPtr domain, const char *to, int flags);
Create a kernel dump of the domain in the path contained in *to. This
API must fail if the domain is not in a panicked/crashed state.
If you set the lowest-bit in flags, however, you can override this
behavior: if the lowest bit is set, the domain will first be crashed
(similar to SysRq-C) - then a dump will be taken from that.
Why?
In the event that a cluster node needs to fence a Xen domain (or other
management tools, to be sure), we could use the API to generate a core
of the domain (if it panicked) to help debug the problem prior to
restarting the domain.
The 'crash-before-dump' bit is just something someone might want to use
at some point; I don't think it is absolutely necessary - but it doesn't
hurt anything either.
-- Lon
9:53 a.m.
On Fri, Nov 03, 2006 at 10:38:18AM -0500, Lon Hohberger wrote:
There's already one for saving live domains:
int virDomainSave(virDomainPtr domain, const char *to);
Why not use a similar API for a function which does the equivalent of
'xm dump' ?
I assume you mean 'xm dump-core' actually
int virDomainDump(virDomainPtr domain, const char *to, int flags);
Create a kernel dump of the domain in the path contained in *to. This
API must fail if the domain is not in a panicked/crashed state.
If you set the lowest-bit in flags, however, you can override this
behavior: if the lowest bit is set, the domain will first be crashed
(similar to SysRq-C) - then a dump will be taken from that.
Why?
In the event that a cluster node needs to fence a Xen domain (or other
management tools, to be sure), we could use the API to generate a core
of the domain (if it panicked) to help debug the problem prior to
restarting the domain.
The 'crash-before-dump' bit is just something someone might want to use
at some point; I don't think it is absolutely necessary - but it doesn't
hurt anything either.
Okay I can see how this would be useful, the questions I would have would be:
- how generic is this, i.e. suppose a different hypervisor back-end
would this still make sense. I guess yes, for example with an UML
back-end we could check the process status and force a dump with a
signal and move the core to the given file not trivial but same semantic
would be doable.
- can we implement it with current xen, again yes, we should be able
if we have a full connection (root) to do the same as 'xm dump-core'
- is the API clean enough, I guess the semantic is relatively clear
instead of stating 'If you set the lowest-bit in flags' I would rather
define a DumpFlags enum and state that flags is an or'ing of any of them
I would probably name the function virDomainDumpCore though to not
confuse with virDomainSave
So yes, why not, you want to work on it ? Or should I (or any candidate).
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
10:36 a.m.
On Fri, 2006-11-03 at 10:53 -0500, Daniel Veillard wrote:
Okay I can see how this would be useful, the questions I would have
would be:
- how generic is this, i.e. suppose a different hypervisor back-end
would this still make sense. I guess yes, for example with an UML
back-end we could check the process status and force a dump with a
signal and move the core to the given file not trivial but same semantic
would be doable.
This I don't know a lot about. I hadn't considered the implications of
using this on non-Xen guests. :o I think I agree with you, though. The
only weird part I can think of with UML is that because it behaves like
a normal process, we'd have to tweak the process's core limit before
causing it to dump...?
- can we implement it with current xen, again yes, we should be
able
if we have a full connection (root) to do the same as 'xm dump-core'
Yes, given that xm dump-core can do it ;)
- is the API clean enough, I guess the semantic is relatively
clear
instead of stating 'If you set the lowest-bit in flags' I would rather
define a DumpFlags enum and state that flags is an or'ing of any of them
I would probably name the function virDomainDumpCore though to not
confuse with virDomainSave
Totally correct here, it should be an enum of flags (with only one
defined initially; I don't know what other flags there might be.
So yes, why not, you want to work on it ? Or should I (or any
candidate).
Give me a few; I'll check on this. I don't have problems trying it, but
I will have a learning curve of course.
-- Lon
10:40 a.m.
On Fri, 2006-11-03 at 11:36 -0500, Lon Hohberger wrote:
> So yes, why not, you want to work on it ? Or should I (or any
candidate).
Give me a few; I'll check on this. I don't have problems trying it, but
I will have a learning curve of course.
Right now, I don't have the time to ramp up my knowledge of libvirt /
xend bits :(
-- Lon
10:56 a.m.
On Fri, Nov 03, 2006 at 11:36:32AM -0500, Lon Hohberger wrote:
On Fri, 2006-11-03 at 10:53 -0500, Daniel Veillard wrote:
> - can we implement it with current xen, again yes, we should be able
> if we have a full connection (root) to do the same as 'xm dump-core'
Yes, given that xm dump-core can do it ;)
> - is the API clean enough, I guess the semantic is relatively clear
> instead of stating 'If you set the lowest-bit in flags' I would
rather
> define a DumpFlags enum and state that flags is an or'ing of any of them
> I would probably name the function virDomainDumpCore though to not
> confuse with virDomainSave
Totally correct here, it should be an enum of flags (with only one
defined initially; I don't know what other flags there might be.
> So yes, why not, you want to work on it ? Or should I (or any candidate).
Give me a few; I'll check on this. I don't have problems trying it, but
I will have a learning curve of course.
Let's see if I was to do it I would:
0/ check out a CVS tree http://libvirt.org/downloads.html
1/ look how xm communicate with xend on that command
2/ isolate another similar entry point from xend_internal.c and
see how to generate the same kind of command but for the core dump
for example xenDaemonDomainSave ()
test by linking statically from a small test program
then the next steps are rather integration problems
3/ extend the back-end driver to add a DumpCore entry point and the
enum in the header (beware it's include/libvirt/libvirt.h.in)
4/ modify all the drivers to have NULL entry points except for the
virDriver xenDaemonDriver one adding the new function at the end.
5/ create the real entry point in libvirt.c, add the initial check for
the flag and the domain status
basically if you just have 1 and 2, sending the diff here I can take care
quickly of the purely integration details,
hope this helps,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:36 a.m.
On Fri, Nov 03, 2006 at 11:56:55AM -0500, Daniel Veillard wrote:
On Fri, Nov 03, 2006 at 11:36:32AM -0500, Lon Hohberger wrote:
> On Fri, 2006-11-03 at 10:53 -0500, Daniel Veillard wrote:
> > - can we implement it with current xen, again yes, we should be able
> > if we have a full connection (root) to do the same as 'xm
dump-core'
>
> Yes, given that xm dump-core can do it ;)
>
> > - is the API clean enough, I guess the semantic is relatively clear
> > instead of stating 'If you set the lowest-bit in flags' I would
rather
> > define a DumpFlags enum and state that flags is an or'ing of any of
them
> > I would probably name the function virDomainDumpCore though to not
> > confuse with virDomainSave
>
> Totally correct here, it should be an enum of flags (with only one
> defined initially; I don't know what other flags there might be.
>
> > So yes, why not, you want to work on it ? Or should I (or any candidate).
>
> Give me a few; I'll check on this. I don't have problems trying it, but
> I will have a learning curve of course.
Let's see if I was to do it I would:
0/ check out a CVS tree http://libvirt.org/downloads.html
1/ look how xm communicate with xend on that command
Bad news, I looked at this and it seems xm can only use the XML-RPC interface
to xend to request the dump command, while libvirt uses the HTTP POST interface.
Adding the support would either require to hack xend or add support for the
intermediary xml-rpc access which was added in 3.0.2 and likely to disapear soon
when the new Xen API is used by xm.
Unfortunately more complex than one could think initially :-\
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:01 a.m.
On Thu, Nov 16, 2006 at 10:36:29AM -0500, Daniel Veillard wrote:
On Fri, Nov 03, 2006 at 11:56:55AM -0500, Daniel Veillard wrote:
> On Fri, Nov 03, 2006 at 11:36:32AM -0500, Lon Hohberger wrote:
> > On Fri, 2006-11-03 at 10:53 -0500, Daniel Veillard wrote:
> > > - can we implement it with current xen, again yes, we should be able
> > > if we have a full connection (root) to do the same as 'xm
dump-core'
> >
> > Yes, given that xm dump-core can do it ;)
> >
> > > - is the API clean enough, I guess the semantic is relatively clear
> > > instead of stating 'If you set the lowest-bit in flags' I
would rather
> > > define a DumpFlags enum and state that flags is an or'ing of any
of them
> > > I would probably name the function virDomainDumpCore though to not
> > > confuse with virDomainSave
> >
> > Totally correct here, it should be an enum of flags (with only one
> > defined initially; I don't know what other flags there might be.
> >
> > > So yes, why not, you want to work on it ? Or should I (or any
candidate).
> >
> > Give me a few; I'll check on this. I don't have problems trying it,
but
> > I will have a learning curve of course.
>
> Let's see if I was to do it I would:
> 0/ check out a CVS tree http://libvirt.org/downloads.html
> 1/ look how xm communicate with xend on that command
Bad news, I looked at this and it seems xm can only use the XML-RPC interface
to xend to request the dump command, while libvirt uses the HTTP POST interface.
Adding the support would either require to hack xend or add support for the
intermediary xml-rpc access which was added in 3.0.2 and likely to disapear soon
when the new Xen API is used by xm.
Good news: the fix at the xend level is fairly small and has been accepted
upstream:
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg01120.html
http://lists.xensource.com/archives/html/xen-devel/2006-11/msg01121.html
So adding dump support was a matter of introducing the new API and calling
the usual xend back-end code. I added it and commited it, it's a new entry
point in the driver interface, I still kept the extra flags argument, even if
upon inspection xend doesn't use any of the 'live' or 'crash' argument
it
exposes at this API, I just didn't defined any constant for it at this point.
So the new entry is just:
int virDomainCoreDump (virDomainPtr domain, const char *to, int flags);
I commited it to CVS, I also added the 'dump' command to virsh taking the
filename as the only argument (after the domain name or id).
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
4:32 a.m.
On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
Okay I can see how this would be useful, the questions I would have would be:
- how generic is this, i.e. suppose a different hypervisor back-end
would this still make sense. I guess yes, for example with an UML
back-end we could check the process status and force a dump with a
signal and move the core to the given file not trivial but same semantic
would be doable.
Is there any policy what should be included in the library? I think
we will see many virtualization projects and an intersection between
all projects could be very small. From my point of view include to
the library something less generic is not big problem if we provide
API with a "non-implemented" (ENOSYS) return codes.
Karel
--
Karel Zak <kzak(a)redhat.com>
5:20 a.m.
On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
>
> Okay I can see how this would be useful, the questions I would have would be:
> - how generic is this, i.e. suppose a different hypervisor back-end
> would this still make sense. I guess yes, for example with an UML
> back-end we could check the process status and force a dump with a
> signal and move the core to the given file not trivial but same semantic
> would be doable.
Is there any policy what should be included in the library? I think
we will see many virtualization projects and an intersection between
all projects could be very small. From my point of view include to
the library something less generic is not big problem if we provide
API with a "non-implemented" (ENOSYS) return codes.
A very specific API is in my experience a wrong one, you end up
accumulating specific APIs instead of finding the right one which
expose a good semantic.
Please forget about "an integer specific return code is good
enough" we clearly aren't following that path, c.f.
http://libvirt.org/errors.html
raising unavailable errors is a good point though.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
5:52 p.m.
On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
>
> Okay I can see how this would be useful, the questions I would have would be:
> - how generic is this, i.e. suppose a different hypervisor back-end
> would this still make sense. I guess yes, for example with an UML
> back-end we could check the process status and force a dump with a
> signal and move the core to the given file not trivial but same semantic
> would be doable.
Is there any policy what should be included in the library? I think
we will see many virtualization projects and an intersection between
all projects could be very small. From my point of view include to
the library something less generic is not big problem if we provide
API with a "non-implemented" (ENOSYS) return codes.
A good sanity check for a proposal is to ask yourself - how would this
be implemented & data represented for QEMU or UserModeLinux, or VMWare.
If you can think of plausible implementations / representations then
that's a good sign the proposal isn't too Xen specific.
For 'xm dump' / virDomainDump() I think its pretty clear all the major
virtualization technologies have some method of dumping a VM's state
so ths API seems sound to me too.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
3:12 a.m.
On Tue, Nov 14, 2006 at 11:52:01PM +0000, Daniel P. Berrange wrote:
On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
> On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
> >
> > Okay I can see how this would be useful, the questions I would have would
be:
> > - how generic is this, i.e. suppose a different hypervisor back-end
> > would this still make sense. I guess yes, for example with an UML
> > back-end we could check the process status and force a dump with a
> > signal and move the core to the given file not trivial but same semantic
> > would be doable.
>
> Is there any policy what should be included in the library? I think
> we will see many virtualization projects and an intersection between
> all projects could be very small. From my point of view include to
> the library something less generic is not big problem if we provide
> API with a "non-implemented" (ENOSYS) return codes.
A good sanity check for a proposal is to ask yourself - how would this
be implemented & data represented for QEMU or UserModeLinux, or VMWare.
If you can think of plausible implementations / representations then
that's a good sign the proposal isn't too Xen specific.
Yes, I understand. But what if we found a feature which is supported
by Xen and VMWare, but is not supported by QEMU? What if we will in
future want to support other virtualization project which is poor for
features? Is possible write libvirt based application which is really
useful, but independent on a virtualization technology?
Nice example is linux kernel and alsa -- it supports many different
sound cards with different features. The kernel doesn't disable use
digital output for my Live! although this feature is not generic for
all sound cards.
Try implement to the virt-manager (or to the applet, or ...)
migration of virtual machines. This is cool feature, but it's Xen
specific -- it means you have to bypass libvirt :-( The result will
be nice and clean libvirt and a lot of dirty applications with
duplicate code which is specific for a technology. Is it expected
result?
Karel
--
Karel Zak <kzak(a)redhat.com>
3:27 a.m.
On Wed, Nov 15, 2006 at 10:12:57AM +0100, Karel Zak wrote:
On Tue, Nov 14, 2006 at 11:52:01PM +0000, Daniel P. Berrange wrote:
> A good sanity check for a proposal is to ask yourself - how would this
> be implemented & data represented for QEMU or UserModeLinux, or VMWare.
> If you can think of plausible implementations / representations then
> that's a good sign the proposal isn't too Xen specific.
Yes, I understand. But what if we found a feature which is supported
by Xen and VMWare, but is not supported by QEMU? What if we will in
future want to support other virtualization project which is poor for
features? Is possible write libvirt based application which is really
useful, but independent on a virtualization technology?
It's an API design issue, not a problem of accepting or rejecting features.
Don't get focused on the wrong issue :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:59 a.m.
On Wed, Nov 15, 2006 at 10:12:57AM +0100, Karel Zak wrote:
On Tue, Nov 14, 2006 at 11:52:01PM +0000, Daniel P. Berrange wrote:
> On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
> > On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
> > >
> > > Okay I can see how this would be useful, the questions I would have
would be:
> > > - how generic is this, i.e. suppose a different hypervisor back-end
> > > would this still make sense. I guess yes, for example with an UML
> > > back-end we could check the process status and force a dump with a
> > > signal and move the core to the given file not trivial but same
semantic
> > > would be doable.
> >
> > Is there any policy what should be included in the library? I think
> > we will see many virtualization projects and an intersection between
> > all projects could be very small. From my point of view include to
> > the library something less generic is not big problem if we provide
> > API with a "non-implemented" (ENOSYS) return codes.
>
> A good sanity check for a proposal is to ask yourself - how would this
> be implemented & data represented for QEMU or UserModeLinux, or VMWare.
> If you can think of plausible implementations / representations then
> that's a good sign the proposal isn't too Xen specific.
Yes, I understand. But what if we found a feature which is supported
by Xen and VMWare, but is not supported by QEMU? What if we will in
future want to support other virtualization project which is poor for
features? Is possible write libvirt based application which is really
useful, but independent on a virtualization technology?
I think it fine to has some APIs which are not supported by every
backend - as long as if QEMU gained that particular feature at a
later date it would be possible to add it in. Take for example the
device hotplug stuff that micheal posted a patch for yesterday. The
original idea was to do an API based on Xen device id - this is clearly
not going to work for a QEMU backend, so we agreed passing in the device
XML blob is a better approach. Now even if we only ever implement the
hotplug stuff for Xen, this API at least gives us option of doing other
implementations if we need to.
Nice example is linux kernel and alsa -- it supports many different
sound cards with different features. The kernel doesn't disable use
digital output for my Live! although this feature is not generic for
all sound cards.
Try implement to the virt-manager (or to the applet, or ...)
migration of virtual machines. This is cool feature, but it's Xen
specific -- it means you have to bypass libvirt :-( The result will
be nice and clean libvirt and a lot of dirty applications with
duplicate code which is specific for a technology. Is it expected
Hopefully not - for most of the stuff we've discussed thus far we've
been able to come up with a representation that is not Xen specific.
I'm optimistic that we'll be able to continue to do this for other
commonly needed things.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
6574
days inactive
6593
days old
12 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Karel Zak -
Lon Hohberger