5:14 a.m.
When libvirt processes VM crash event it always dumps core in raw
format.
This series makes it possible to configure dump format via domain xml.
This would be especcialy helpful for Windows guests, because it requires
a lot effort to convert raw dump into wingdb.
Nikolai Barybin (4):
conf: schemas: add coredump_format element to events section
src: conf: add parsing/formatting for 'coredump_format' value
qemu: use configurable dump format in doCoreDumpToAutoDumpPath()
docs: formatdomain: document 'coredump_format' element
docs/formatdomain.rst | 9 +++++
src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 2 +
src/conf/schemas/domaincommon.rng | 19 +++++++++
src/libvirt_private.syms | 2 +
src/qemu/qemu_driver.c | 2 +-
6 files changed, 97 insertions(+), 1 deletion(-)
--
2.43.5
5:14 a.m.
New subject: [PATCH 1/4] conf: schemas: add coredump_format element to events section
Signed-off-by: Nikolai Barybin <nikolai.barybin(a)virtuozzo.com>
---
src/conf/schemas/domaincommon.rng | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index 5597d5a66b..dc8f708779 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -4816,6 +4816,11 @@
<ref name="crashOptions"/>
</element>
</optional>
+ <optional>
+ <element name="coredump_format">
+ <ref name="coredumpFormat"/>
+ </element>
+ </optional>
<optional>
<element name="on_lockfailure">
<ref name="lockfailureOptions"/>
@@ -4862,6 +4867,20 @@
<value>coredump-restart</value>
</choice>
</define>
+ <!--
+ Spicifies domain's coredump format when 'coredump-destroy' or
'coredump-restart'
+ are chosen in crashOptions.
+ Default value is 'raw'.
+ -->
+ <define name="coredumpFormat">
+ <choice>
+ <value>raw</value>
+ <value>kdump-zlib</value>
+ <value>kdump-lzo</value>
+ <value>kdump-snappy</value>
+ <value>win-dmp</value>
+ </choice>
+ </define>
<!--
Options when resource locks are lost:
poweroff: power off the domain
--
2.43.5
5:14 a.m.
New subject: [PATCH 2/4] src: conf: add parsing/formatting for 'coredump_format' value
Signed-off-by: Nikolai Barybin <nikolai.barybin(a)virtuozzo.com>
---
src/conf/domain_conf.c | 64 ++++++++++++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 2 ++
src/libvirt_private.syms | 2 ++
3 files changed, 68 insertions(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 99ecb03067..89dceacf79 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -303,6 +303,15 @@ VIR_ENUM_IMPL(virDomainLifecycleAction,
"coredump-restart",
);
+VIR_ENUM_IMPL(virDomainCoreDumpFormat,
+ VIR_DOMAIN_CORE_DUMP_FORMAT_LAST,
+ "raw",
+ "kdump-zlib",
+ "kdump-lzo",
+ "kdump-snappy",
+ "win-dmp",
+);
+
VIR_ENUM_IMPL(virDomainLockFailure,
VIR_DOMAIN_LOCK_FAILURE_LAST,
"default",
@@ -13820,6 +13829,29 @@ virDomainRedirFilterDefParseXML(xmlNodePtr node,
return NULL;
}
+static int
+virDomainCoredumpFormatParseXML(xmlXPathContextPtr ctxt,
+ const char *name,
+ const char *xpath,
+ int *val,
+ int defaultVal,
+ virEventActionFromStringFunc convFunc)
+{
+ g_autofree char *tmp = virXPathString(xpath, ctxt);
+
+ if (tmp == NULL) {
+ *val = defaultVal;
+ } else {
+ *val = convFunc(tmp);
+ if (*val < 0) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("unknown %1$s format: %2$s"), name, tmp);
+ return -1;
+ }
+ }
+ return 0;
+}
+
static int
virDomainEventActionParseXML(xmlXPathContextPtr ctxt,
const char *name,
@@ -19163,6 +19195,13 @@ virDomainDefLifecycleParse(virDomainDef *def,
virDomainLifecycleActionTypeFromString) < 0)
return -1;
+ if (virDomainCoredumpFormatParseXML(ctxt, "coredump_format",
+ "string(./coredump_format[1])",
+ &def->coredumpFormat,
+ VIR_DOMAIN_CORE_DUMP_FORMAT_RAW,
+ virDomainCoreDumpFormatTypeFromString) < 0)
+ return -1;
+
if (virDomainEventActionParseXML(ctxt, "on_lockfailure",
"string(./on_lockfailure[1])",
&def->onLockFailure,
@@ -22857,6 +22896,25 @@ virDomainEventActionDefFormat(virBuffer *buf,
}
+static int
+virDomainCoreDumpFormatDefFormat(virBuffer *buf,
+ int type,
+ const char *name,
+ virEventActionToStringFunc convFunc)
+{
+ const char *typeStr = convFunc(type);
+ if (!typeStr) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("unexpected %1$s coredump format: %2$d"), name,
type);
+ return -1;
+ }
+
+ virBufferAsprintf(buf, "<%s>%s</%s>\n", name, typeStr, name);
+
+ return 0;
+}
+
+
static void
virSecurityLabelDefFormat(virBuffer *buf,
virSecurityLabelDef *def,
@@ -29023,6 +29081,12 @@ virDomainDefFormatInternalSetRootName(virDomainDef *def,
"on_crash",
virDomainLifecycleActionTypeToString) < 0)
return -1;
+ if ((def->onCrash == VIR_DOMAIN_LIFECYCLE_ACTION_COREDUMP_DESTROY ||
+ def->onCrash == VIR_DOMAIN_LIFECYCLE_ACTION_COREDUMP_RESTART) &&
+ virDomainCoreDumpFormatDefFormat(buf, def->coredumpFormat,
+ "coredump_format",
+ virDomainCoreDumpFormatTypeToString) < 0)
+ return -1;
if (def->onLockFailure != VIR_DOMAIN_LOCK_FAILURE_DEFAULT &&
virDomainEventActionDefFormat(buf, def->onLockFailure,
"on_lockfailure",
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 0d1dd954ae..6e43282160 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -3144,6 +3144,7 @@ struct _virDomainDef {
int onReboot;
int onPoweroff;
int onCrash;
+ int coredumpFormat;
int onLockFailure; /* enum virDomainLockFailureAction */
@@ -4281,6 +4282,7 @@ VIR_ENUM_DECL(virDomainCapabilitiesPolicy);
VIR_ENUM_DECL(virDomainProcessCapsFeature);
VIR_ENUM_DECL(virDomainLifecycle);
VIR_ENUM_DECL(virDomainLifecycleAction);
+VIR_ENUM_DECL(virDomainCoreDumpFormat);
VIR_ENUM_DECL(virDomainDevice);
VIR_ENUM_DECL(virDomainDiskDevice);
VIR_ENUM_DECL(virDomainDiskGeometryTrans);
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 812fa4e435..72f9e3418f 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -303,6 +303,8 @@ virDomainControllerPCIModelNameTypeFromString;
virDomainControllerPCIModelNameTypeToString;
virDomainControllerRemove;
virDomainControllerTypeToString;
+virDomainCoreDumpFormatTypeFromString;
+virDomainCoreDumpFormatTypeToString;
virDomainCpuPlacementModeTypeFromString;
virDomainCpuPlacementModeTypeToString;
virDomainCryptoBackendTypeFromString;
--
2.43.5
5:14 a.m.
New subject: [PATCH 3/4] qemu: use configurable dump format in doCoreDumpToAutoDumpPath()
Instead of doing dump in raw format, let's use configurable
vm->def->coredumpFormat, which is either way will be raw by default.
Signed-off-by: Nikolai Barybin <nikolai.barybin(a)virtuozzo.com>
---
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 6ce949dd07..961e1eb2e8 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -3470,7 +3470,7 @@ doCoreDumpToAutoDumpPath(virQEMUDriver *driver,
flags |= cfg->autoDumpBypassCache ? VIR_DUMP_BYPASS_CACHE: 0;
if ((ret = doCoreDump(driver, vm, dumpfile, flags,
- VIR_DOMAIN_CORE_DUMP_FORMAT_RAW)) < 0)
+ vm->def->coredumpFormat)) < 0)
virReportError(VIR_ERR_OPERATION_FAILED,
"%s", _("Dump failed"));
return ret;
--
2.43.5
5:14 a.m.
New subject: [PATCH 4/4] docs: formatdomain: document 'coredump_format' element
Signed-off-by: Nikolai Barybin <nikolai.barybin(a)virtuozzo.com>
---
docs/formatdomain.rst | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 3be7ee0ff4..edd9762fd4 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -1957,6 +1957,15 @@ The ``on_crash`` event supports these additional actions
:since:`since 0.8.4`.
The crashed domain's core will be dumped, and then the domain will be
restarted with the same configuration
+The crashed domain's core format may be specified by ``coredump_format`` element:
+ ...
+ <on_crash>coredump-destroy</on_crash>
+ <coredum_format>raw</coredump_format>
+ ...
+
+The possible values are ``raw`` (default), ``kdump-zlib``, ``kdump-lzo``,
``kdump-snappy``,
+``win-dmp``.
+
:since:`Since 3.9.0`, the lifecycle events can be configured via the
`virDomainSetLifecycleAction
<html/libvirt-libvirt-domain.html#virDomainSetLifecycleAction>`__
API.
--
2.43.5
11:45 a.m.
On 3/27/25 11:14, Nikolai Barybin wrote:
When libvirt processes VM crash event it always dumps core in raw
format.
This series makes it possible to configure dump format via domain xml.
This would be especcialy helpful for Windows guests, because it requires
a lot effort to convert raw dump into wingdb.
Nikolai Barybin (4):
conf: schemas: add coredump_format element to events section
src: conf: add parsing/formatting for 'coredump_format' value
qemu: use configurable dump format in doCoreDumpToAutoDumpPath()
docs: formatdomain: document 'coredump_format' element
docs/formatdomain.rst | 9 +++++
src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++
src/conf/domain_conf.h | 2 +
src/conf/schemas/domaincommon.rng | 19 +++++++++
src/libvirt_private.syms | 2 +
src/qemu/qemu_driver.c | 2 +-
6 files changed, 97 insertions(+), 1 deletion(-)
The idea is that correct Windows dump could be collected
only at the moment of the dump collection as dump
collector code in QEMU uses some information from
Windows drivers. Later conversion using external tools
proven to be complex.
That is why we either should specify the type of the
dump inside the configuration file or autoguess the
format. I though that latter could be implemented as
the next step using f.e. presence of HyperV feature or
checking OS type in metadata.
I think that this thing would be useful.
Den
5:15 a.m.
On Fri, Mar 28, 2025 at 05:45:12PM +0100, Denis V. Lunev via Devel wrote:
On 3/27/25 11:14, Nikolai Barybin wrote:
> When libvirt processes VM crash event it always dumps core in raw
> format.
>
> This series makes it possible to configure dump format via domain xml.
> This would be especcialy helpful for Windows guests, because it requires
> a lot effort to convert raw dump into wingdb.
>
> Nikolai Barybin (4):
> conf: schemas: add coredump_format element to events section
> src: conf: add parsing/formatting for 'coredump_format' value
> qemu: use configurable dump format in doCoreDumpToAutoDumpPath()
> docs: formatdomain: document 'coredump_format' element
>
> docs/formatdomain.rst | 9 +++++
> src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++
> src/conf/domain_conf.h | 2 +
> src/conf/schemas/domaincommon.rng | 19 +++++++++
> src/libvirt_private.syms | 2 +
> src/qemu/qemu_driver.c | 2 +-
> 6 files changed, 97 insertions(+), 1 deletion(-)
>
The idea is that correct Windows dump could be collected
only at the moment of the dump collection as dump
collector code in QEMU uses some information from
Windows drivers. Later conversion using external tools
proven to be complex.
That is why we either should specify the type of the
dump inside the configuration file or autoguess the
format. I though that latter could be implemented as
the next step using f.e. presence of HyperV feature or
checking OS type in metadata.
I think that this thing would be useful.
Effectively QEMU has three dump formats - WinDump, KDump and ELF,
with the KDump format being overloaded to express 6 different
sub-variants.
The global qemu.conf setting is effectively useless as far as
the 'win-dmp' format goes, because it is highly unlikely to
have a single host running exclusively windows guests.
Anyone know if the KDump format is only interesting for Linux
guests, or can it be useful for dumping any guest OS types ?
Looking at the QEMU impl, IIUC the WinDump format can only be requested
if the guest OS has exposed the Win Dump note in fw_cfg via the vmcoreinfo
device, otherwise we'll hit a hard error on the check
if (s->guest_note_size != VMCOREINFO_WIN_DUMP_NOTE_SIZE32 &&
s->guest_note_size != VMCOREINFO_WIN_DUMP_NOTE_SIZE64) {
error_setg(errp, "win-dump: invalid vmcoreinfo note size");
return;
}
This in turn depends on whether the KVM guest drivers are installed in
the guest. IOW, we can't auto-choose WinDump merely based on presence
of the HyperV fature, nor even libosinfo OS type in metadata.
QEMU itself should always knows whether or not it can use WinDump format,
as it can see the fw_cfg data, but I can't see any way this is exposed
to the mgmt app, but potentially that could be expressed via a new qmp
command if needed ?
Essentially I'm wondering whether there's any pratical way we can
"do the right thing" without manual configuration of each guest ?
If it is just a choice between using win-dmp vs the qemu.conf setting
it might be doable, assuming the various kdump,elf formats are viable
for /all/ guest types. If we needed to auto-detct kdump vs elf it gets
harder
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:26 a.m.
On 4/2/25 12:15, Daniel P. Berrangé wrote:
On Fri, Mar 28, 2025 at 05:45:12PM +0100, Denis V. Lunev via Devel
wrote:
> On 3/27/25 11:14, Nikolai Barybin wrote:
>> When libvirt processes VM crash event it always dumps core in raw
>> format.
>>
>> This series makes it possible to configure dump format via domain xml.
>> This would be especcialy helpful for Windows guests, because it requires
>> a lot effort to convert raw dump into wingdb.
>>
>> Nikolai Barybin (4):
>> conf: schemas: add coredump_format element to events section
>> src: conf: add parsing/formatting for 'coredump_format' value
>> qemu: use configurable dump format in doCoreDumpToAutoDumpPath()
>> docs: formatdomain: document 'coredump_format' element
>>
>> docs/formatdomain.rst | 9 +++++
>> src/conf/domain_conf.c | 64 +++++++++++++++++++++++++++++++
>> src/conf/domain_conf.h | 2 +
>> src/conf/schemas/domaincommon.rng | 19 +++++++++
>> src/libvirt_private.syms | 2 +
>> src/qemu/qemu_driver.c | 2 +-
>> 6 files changed, 97 insertions(+), 1 deletion(-)
>>
> The idea is that correct Windows dump could be collected
> only at the moment of the dump collection as dump
> collector code in QEMU uses some information from
> Windows drivers. Later conversion using external tools
> proven to be complex.
>
> That is why we either should specify the type of the
> dump inside the configuration file or autoguess the
> format. I though that latter could be implemented as
> the next step using f.e. presence of HyperV feature or
> checking OS type in metadata.
>
> I think that this thing would be useful.
Effectively QEMU has three dump formats - WinDump, KDump and ELF,
with the KDump format being overloaded to express 6 different
sub-variants.
The global qemu.conf setting is effectively useless as far as
the 'win-dmp' format goes, because it is highly unlikely to
have a single host running exclusively windows guests.
Anyone know if the KDump format is only interesting for Linux
guests, or can it be useful for dumping any guest OS types ?
Looking at the QEMU impl, IIUC the WinDump format can only be requested
if the guest OS has exposed the Win Dump note in fw_cfg via the vmcoreinfo
device, otherwise we'll hit a hard error on the check
if (s->guest_note_size != VMCOREINFO_WIN_DUMP_NOTE_SIZE32 &&
s->guest_note_size != VMCOREINFO_WIN_DUMP_NOTE_SIZE64) {
error_setg(errp, "win-dump: invalid vmcoreinfo note size");
return;
}
This in turn depends on whether the KVM guest drivers are installed in
the guest. IOW, we can't auto-choose WinDump merely based on presence
of the HyperV fature, nor even libosinfo OS type in metadata.
QEMU itself should always knows whether or not it can use WinDump format,
as it can see the fw_cfg data, but I can't see any way this is exposed
to the mgmt app, but potentially that could be expressed via a new qmp
command if needed ?
Essentially I'm wondering whether there's any pratical way we can
"do the right thing" without manual configuration of each guest ?
If it is just a choice between using win-dmp vs the qemu.conf setting
it might be doable, assuming the various kdump,elf formats are viable
for /all/ guest types. If we needed to auto-detct kdump vs elf it gets
harder
With regards,
Daniel
Hello everyone!
I didn't clearly get the outcome of previous discussion. Could you
clarify whether we plan to review/merge these patches or drop them?
Best regards,
Nikolai Barybin
5:01 a.m.
On Wed, Apr 02, 2025 at 11:15:41AM +0100, Daniel P. Berrangé via Devel wrote:
QEMU itself should always knows whether or not it can use WinDump
format,
as it can see the fw_cfg data, but I can't see any way this is exposed
to the mgmt app, but potentially that could be expressed via a new qmp
command if needed ?
Essentially I'm wondering whether there's any pratical way we can
"do the right thing" without manual configuration of each guest ?
So QEMU exposes a QMP command
(QEMU) query-dump-guest-memory-capability
{"return": {"formats": ["elf", "kdump-zlib",
"kdump-raw-zlib", "kdump-lzo", "kdump-raw-lzo",
"kdump-snappy", "kdump-raw-snappy", "win-dmp"]}}
but this is a lie
(QEMU) dump-guest-memory format=win-dmp paging=false protocol=file:foo.dmp
{"error": {"class": "GenericError", "desc":
"win-dump: invalid vmcoreinfo note size"}}
QEMU's impl of 'query-dump-guest-memory-capability' does
if (win_dump_available(NULL)) {
QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_WIN_DMP);
}
where win_dump_available is:
#if defined(TARGET_X86_64)
bool win_dump_available(Error **errp)
{
return true;
}
#else
bool win_dump_available(Error **errp)
{
error_setg(errp, "Windows dump is only available for x86-64");
return false;
}
#endif
This is a broken impl IMHO, as it should only report 'win-dump' if the
running guest is actually capable of it.
If it is just a choice between using win-dmp vs the qemu.conf
setting
it might be doable, assuming the various kdump,elf formats are viable
for /all/ guest types. If we needed to auto-detct kdump vs elf it gets
harder
Assuming we can fix QEMU to accurately report 'win-dump', then we can
make libvirt "do the right thing(tm)" out of the box, without needing
a per-guest XML knob.
ie, if 'win-dump' is reported as available, use that, otherwise use
the format configured in qemu.conf.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
5
days inactive
108
days old
8 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Denis V. Lunev -
Nikolai Barybin