10:02 p.m.
Now, virsh dump doesn't support compresses dump.
This patch adds GZIP and LZOP option to virsh dump and support
it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
When I did 4G guest dump,
(Raw) 3844669750
(Gzip) 1029846577
(LZOP) 1416263880 (faster than gzip in general)
This will be a help for a host where crash-dump is used
and several guests works on it.
help message is modified as this.
NAME
dump - dump the core of a domain to a file for analysis
SYNOPSIS
dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
DESCRIPTION
Core dump a domain.
OPTIONS
--live perform a live core dump if supported
--crash crash the domain after core dump
--gzip gzip dump(only one compression allowed
--lzop lzop dump(only one compression allowed
[--domain] <string> domain name, id or uuid
[--file] <string> where to dump the core
Tested on Fedora-13+x86-64.
Note: for better compression, we may have to skip pages filled by
zero or freed pages. But it seems it's qemu's works.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>
---
include/libvirt/libvirt.h.in | 2 ++
src/qemu/qemu_driver.c | 23 +++++++++++++++++++----
tools/virsh.c | 10 +++++++++-
3 files changed, 30 insertions(+), 5 deletions(-)
Index: libvirt-0.8.4/src/qemu/qemu_driver.c
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_driver.c
+++ libvirt-0.8.4/src/qemu/qemu_driver.c
@@ -5710,7 +5710,7 @@ cleanup:
static int qemudDomainCoreDump(virDomainPtr dom,
const char *path,
- int flags ATTRIBUTE_UNUSED) {
+ int flags) {
struct qemud_driver *driver = dom->conn->privateData;
virDomainObjPtr vm;
int resume = 0, paused = 0;
@@ -5720,6 +5720,14 @@ static int qemudDomainCoreDump(virDomain
"cat",
NULL,
};
+ const char *zargs[] = {
+ "gzip",
+ NULL,
+ };
+ const char *lzargs[] = {
+ "lzop",
+ NULL,
+ };
qemuDomainObjPrivatePtr priv;
qemuDriverLock(driver);
@@ -5787,9 +5795,16 @@ static int qemudDomainCoreDump(virDomain
}
qemuDomainObjEnterMonitorWithDriver(driver, vm);
- ret = qemuMonitorMigrateToFile(priv->mon,
- QEMU_MONITOR_MIGRATE_BACKGROUND,
- args, path, 0);
+ if (flags & VIR_DUMP_GZIP)
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, zargs, path, 0);
+ else if (flags & VIR_DUMP_LZOP)
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, lzargs, path, 0);
+ else
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, args, path, 0);
+
qemuDomainObjExitMonitorWithDriver(driver, vm);
if (ret < 0)
goto endjob;
Index: libvirt-0.8.4/tools/virsh.c
===================================================================
--- libvirt-0.8.4.orig/tools/virsh.c
+++ libvirt-0.8.4/tools/virsh.c
@@ -1751,6 +1751,8 @@ static const vshCmdInfo info_dump[] = {
static const vshCmdOptDef opts_dump[] = {
{"live", VSH_OT_BOOL, 0, N_("perform a live core dump if
supported")},
{"crash", VSH_OT_BOOL, 0, N_("crash the domain after core
dump")},
+ {"gzip", VSH_OT_BOOL, 0, N_("gzip dump(only one compression
allowed")},
+ {"lzop", VSH_OT_BOOL, 0, N_("lzop dump(only one compression
allowed")},
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or
uuid")},
{"file", VSH_OT_DATA, VSH_OFLAG_REQ, N_("where to dump the
core")},
{NULL, 0, 0, NULL}
@@ -1778,7 +1780,13 @@ cmdDump(vshControl *ctl, const vshCmd *c
flags |= VIR_DUMP_LIVE;
if (vshCommandOptBool (cmd, "crash"))
flags |= VIR_DUMP_CRASH;
-
+ if (vshCommandOptBool (cmd, "gzip"))
+ flags |= VIR_DUMP_GZIP;
+ if (vshCommandOptBool (cmd, "lzop"))
+ flags |= VIR_DUMP_LZOP;
+ if ((flags & (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
+ == (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
+ return FALSE;
if (virDomainCoreDump(dom, to, flags) == 0) {
vshPrint(ctl, _("Domain %s dumped to %s\n"), name, to);
} else {
Index: libvirt-0.8.4/include/libvirt/libvirt.h.in
===================================================================
--- libvirt-0.8.4.orig/include/libvirt/libvirt.h.in
+++ libvirt-0.8.4/include/libvirt/libvirt.h.in
@@ -402,6 +402,8 @@ typedef virDomainMemoryStatStruct *virDo
typedef enum {
VIR_DUMP_CRASH = (1 << 0), /* crash after dump */
VIR_DUMP_LIVE = (1 << 1), /* live dump */
+ VIR_DUMP_GZIP = (1 << 2), /* gzip dump file */
+ VIR_DUMP_LZOP = (1 << 3), /* lzop dump file */
} virDomainCoreDumpFlags;
/* Domain migration flags. */
3:35 a.m.
On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
Now, virsh dump doesn't support compresses dump.
This patch adds GZIP and LZOP option to virsh dump and support
it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
When I did 4G guest dump,
(Raw) 3844669750
(Gzip) 1029846577
(LZOP) 1416263880 (faster than gzip in general)
This will be a help for a host where crash-dump is used
and several guests works on it.
help message is modified as this.
NAME
dump - dump the core of a domain to a file for analysis
SYNOPSIS
dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
DESCRIPTION
Core dump a domain.
OPTIONS
--live perform a live core dump if supported
--crash crash the domain after core dump
--gzip gzip dump(only one compression allowed
--lzop lzop dump(only one compression allowed
[--domain] <string> domain name, id or uuid
[--file] <string> where to dump the core
Tested on Fedora-13+x86-64.
Note: for better compression, we may have to skip pages filled by
zero or freed pages. But it seems it's qemu's works.
The patch looks relatively simple and clean, I still have one comemnt
below though. It also seems to me that any use of the dump need a follow
up decompression before it can be fed to debug tools (gdb ...) as I
don't think they handle compressed dumps natively.
The other comment on principle about this patch is that for saving
compression we use a qemu.conf option, maybe we should instead use
a new option there for core compression, or simply reuse the same
option for both (core being just a special kind of save). You will
also note that save_image_format takes more options than lzop or gzip.
If doing so one doesn't need to change virsh too.
It's a trade off. If using the configuration option you need to plan
in advance the fact you will be dumping compressed core, if you expose
it at the API level itself, you can activate it anytime, and that may be
more useful for example when interacting with a customer facing an
issue needing debug. So both ways are acceptable to me.
Signed-off-by: KAMEZAWA Hiroyuki
<kamezawa.hiroyu(a)jp.fujitsu.com>
---
include/libvirt/libvirt.h.in | 2 ++
src/qemu/qemu_driver.c | 23 +++++++++++++++++++----
tools/virsh.c | 10 +++++++++-
3 files changed, 30 insertions(+), 5 deletions(-)
Index: libvirt-0.8.4/src/qemu/qemu_driver.c
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_driver.c
+++ libvirt-0.8.4/src/qemu/qemu_driver.c
@@ -5710,7 +5710,7 @@ cleanup:
static int qemudDomainCoreDump(virDomainPtr dom,
const char *path,
- int flags ATTRIBUTE_UNUSED) {
+ int flags) {
struct qemud_driver *driver = dom->conn->privateData;
virDomainObjPtr vm;
int resume = 0, paused = 0;
@@ -5720,6 +5720,14 @@ static int qemudDomainCoreDump(virDomain
"cat",
NULL,
};
+ const char *zargs[] = {
+ "gzip",
+ NULL,
+ };
+ const char *lzargs[] = {
+ "lzop",
+ NULL,
+ };
qemuDomainObjPrivatePtr priv;
qemuDriverLock(driver);
@@ -5787,9 +5795,16 @@ static int qemudDomainCoreDump(virDomain
}
qemuDomainObjEnterMonitorWithDriver(driver, vm);
- ret = qemuMonitorMigrateToFile(priv->mon,
- QEMU_MONITOR_MIGRATE_BACKGROUND,
- args, path, 0);
+ if (flags & VIR_DUMP_GZIP)
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, zargs, path, 0);
+ else if (flags & VIR_DUMP_LZOP)
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, lzargs, path, 0);
+ else
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND, args, path, 0);
+
I'm wondering what happens if the compression command is not present,
if the current error message we get back from qemu is clear enough then
fine, but otherwise we may have to check for the presence of the
compressor program.
qemuDomainObjExitMonitorWithDriver(driver, vm);
if (ret < 0)
goto endjob;
Index: libvirt-0.8.4/tools/virsh.c
===================================================================
--- libvirt-0.8.4.orig/tools/virsh.c
+++ libvirt-0.8.4/tools/virsh.c
@@ -1751,6 +1751,8 @@ static const vshCmdInfo info_dump[] = {
static const vshCmdOptDef opts_dump[] = {
{"live", VSH_OT_BOOL, 0, N_("perform a live core dump if
supported")},
{"crash", VSH_OT_BOOL, 0, N_("crash the domain after core
dump")},
+ {"gzip", VSH_OT_BOOL, 0, N_("gzip dump(only one compression
allowed")},
+ {"lzop", VSH_OT_BOOL, 0, N_("lzop dump(only one compression
allowed")},
what about bzip2 and xz, the first one is probably way too slow, but
we accept it for saves.
{"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain
name, id or uuid")},
{"file", VSH_OT_DATA, VSH_OFLAG_REQ, N_("where to dump the
core")},
{NULL, 0, 0, NULL}
@@ -1778,7 +1780,13 @@ cmdDump(vshControl *ctl, const vshCmd *c
flags |= VIR_DUMP_LIVE;
if (vshCommandOptBool (cmd, "crash"))
flags |= VIR_DUMP_CRASH;
-
+ if (vshCommandOptBool (cmd, "gzip"))
+ flags |= VIR_DUMP_GZIP;
+ if (vshCommandOptBool (cmd, "lzop"))
+ flags |= VIR_DUMP_LZOP;
+ if ((flags & (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
+ == (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
+ return FALSE;
I think an error message need to be provided stating that both options
are mutually exclusive.
Otherwise that looks fine to me,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
3:58 a.m.
On Thu, 21 Oct 2010 10:35:10 +0200
Daniel Veillard <veillard(a)redhat.com> wrote:
On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
>
> Now, virsh dump doesn't support compresses dump.
> This patch adds GZIP and LZOP option to virsh dump and support
> it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
>
> When I did 4G guest dump,
> (Raw) 3844669750
> (Gzip) 1029846577
> (LZOP) 1416263880 (faster than gzip in general)
>
> This will be a help for a host where crash-dump is used
> and several guests works on it.
>
> help message is modified as this.
> NAME
> dump - dump the core of a domain to a file for analysis
>
> SYNOPSIS
> dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
>
> DESCRIPTION
> Core dump a domain.
>
> OPTIONS
> --live perform a live core dump if supported
> --crash crash the domain after core dump
> --gzip gzip dump(only one compression allowed
> --lzop lzop dump(only one compression allowed
> [--domain] <string> domain name, id or uuid
> [--file] <string> where to dump the core
>
> Tested on Fedora-13+x86-64.
>
> Note: for better compression, we may have to skip pages filled by
> zero or freed pages. But it seems it's qemu's works.
Thank you for review.
The patch looks relatively simple and clean, I still have one
comemnt
below though. It also seems to me that any use of the dump need a follow
up decompression before it can be fed to debug tools (gdb ...) as I
don't think they handle compressed dumps natively.
Yes. But at support-job, coredump must be transfered to support-team enviroment
in many case. In that case, dump image tend to be compressed.
The other comment on principle about this patch is that for saving
compression we use a qemu.conf option, maybe we should instead use
a new option there for core compression, or simply reuse the same
option for both (core being just a special kind of save). You will
also note that save_image_format takes more options than lzop or gzip.
If doing so one doesn't need to change virsh too.
Ah, okay, this one ?
http://www.mail-archive.com/libvir-list@redhat.com/msg15564.html
Doesn't this affect behaviors other than dump ?
It's a trade off. If using the configuration option you need to
plan
in advance the fact you will be dumping compressed core, if you expose
it at the API level itself, you can activate it anytime, and that may be
more useful for example when interacting with a customer facing an
issue needing debug. So both ways are acceptable to me.
Sure.
> Signed-off-by: KAMEZAWA Hiroyuki
<kamezawa.hiroyu(a)jp.fujitsu.com>
> ---
> include/libvirt/libvirt.h.in | 2 ++
> src/qemu/qemu_driver.c | 23 +++++++++++++++++++----
> tools/virsh.c | 10 +++++++++-
> 3 files changed, 30 insertions(+), 5 deletions(-)
>
> Index: libvirt-0.8.4/src/qemu/qemu_driver.c
> ===================================================================
> --- libvirt-0.8.4.orig/src/qemu/qemu_driver.c
> +++ libvirt-0.8.4/src/qemu/qemu_driver.c
> @@ -5710,7 +5710,7 @@ cleanup:
>
> static int qemudDomainCoreDump(virDomainPtr dom,
> const char *path,
> - int flags ATTRIBUTE_UNUSED) {
> + int flags) {
> struct qemud_driver *driver = dom->conn->privateData;
> virDomainObjPtr vm;
> int resume = 0, paused = 0;
> @@ -5720,6 +5720,14 @@ static int qemudDomainCoreDump(virDomain
> "cat",
> NULL,
> };
> + const char *zargs[] = {
> + "gzip",
> + NULL,
> + };
> + const char *lzargs[] = {
> + "lzop",
> + NULL,
> + };
> qemuDomainObjPrivatePtr priv;
>
> qemuDriverLock(driver);
> @@ -5787,9 +5795,16 @@ static int qemudDomainCoreDump(virDomain
> }
>
> qemuDomainObjEnterMonitorWithDriver(driver, vm);
> - ret = qemuMonitorMigrateToFile(priv->mon,
> - QEMU_MONITOR_MIGRATE_BACKGROUND,
> - args, path, 0);
> + if (flags & VIR_DUMP_GZIP)
> + ret = qemuMonitorMigrateToFile(priv->mon,
> + QEMU_MONITOR_MIGRATE_BACKGROUND, zargs, path, 0);
> + else if (flags & VIR_DUMP_LZOP)
> + ret = qemuMonitorMigrateToFile(priv->mon,
> + QEMU_MONITOR_MIGRATE_BACKGROUND, lzargs, path, 0);
> + else
> + ret = qemuMonitorMigrateToFile(priv->mon,
> + QEMU_MONITOR_MIGRATE_BACKGROUND, args, path, 0);
> +
I'm wondering what happens if the compression command is not present,
if the current error message we get back from qemu is clear enough then
fine, but otherwise we may have to check for the presence of the
compressor program.
Ok, I will add check code. But hmm, calling system() for checking command
exists is ok ? Or some good function do we have ?
> qemuDomainObjExitMonitorWithDriver(driver, vm);
> if (ret < 0)
> goto endjob;
> Index: libvirt-0.8.4/tools/virsh.c
> ===================================================================
> --- libvirt-0.8.4.orig/tools/virsh.c
> +++ libvirt-0.8.4/tools/virsh.c
> @@ -1751,6 +1751,8 @@ static const vshCmdInfo info_dump[] = {
> static const vshCmdOptDef opts_dump[] = {
> {"live", VSH_OT_BOOL, 0, N_("perform a live core dump if
supported")},
> {"crash", VSH_OT_BOOL, 0, N_("crash the domain after core
dump")},
> + {"gzip", VSH_OT_BOOL, 0, N_("gzip dump(only one compression
allowed")},
> + {"lzop", VSH_OT_BOOL, 0, N_("lzop dump(only one compression
allowed")},
what about bzip2 and xz, the first one is probably way too slow, but
we accept it for saves.
will add bzip2 and xz. (but maybe very slow.)
> {"domain", VSH_OT_DATA, VSH_OFLAG_REQ,
N_("domain name, id or uuid")},
> {"file", VSH_OT_DATA, VSH_OFLAG_REQ, N_("where to dump the
core")},
> {NULL, 0, 0, NULL}
> @@ -1778,7 +1780,13 @@ cmdDump(vshControl *ctl, const vshCmd *c
> flags |= VIR_DUMP_LIVE;
> if (vshCommandOptBool (cmd, "crash"))
> flags |= VIR_DUMP_CRASH;
> -
> + if (vshCommandOptBool (cmd, "gzip"))
> + flags |= VIR_DUMP_GZIP;
> + if (vshCommandOptBool (cmd, "lzop"))
> + flags |= VIR_DUMP_LZOP;
> + if ((flags & (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
> + == (VIR_DUMP_GZIP | VIR_DUMP_LZOP))
> + return FALSE;
I think an error message need to be provided stating that both options
are mutually exclusive.
I'll add one.
Thank you.
-Kame
4:26 a.m.
On Thu, Oct 21, 2010 at 10:35:10AM +0200, Daniel Veillard wrote:
On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
>
> Now, virsh dump doesn't support compresses dump.
> This patch adds GZIP and LZOP option to virsh dump and support
> it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
>
> When I did 4G guest dump,
> (Raw) 3844669750
> (Gzip) 1029846577
> (LZOP) 1416263880 (faster than gzip in general)
>
> This will be a help for a host where crash-dump is used
> and several guests works on it.
>
> help message is modified as this.
> NAME
> dump - dump the core of a domain to a file for analysis
>
> SYNOPSIS
> dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
>
> DESCRIPTION
> Core dump a domain.
>
> OPTIONS
> --live perform a live core dump if supported
> --crash crash the domain after core dump
> --gzip gzip dump(only one compression allowed
> --lzop lzop dump(only one compression allowed
> [--domain] <string> domain name, id or uuid
> [--file] <string> where to dump the core
>
> Tested on Fedora-13+x86-64.
>
> Note: for better compression, we may have to skip pages filled by
> zero or freed pages. But it seems it's qemu's works.
The patch looks relatively simple and clean, I still have one comemnt
below though. It also seems to me that any use of the dump need a follow
up decompression before it can be fed to debug tools (gdb ...) as I
don't think they handle compressed dumps natively.
The other comment on principle about this patch is that for saving
compression we use a qemu.conf option, maybe we should instead use
a new option there for core compression, or simply reuse the same
option for both (core being just a special kind of save). You will
also note that save_image_format takes more options than lzop or gzip.
If doing so one doesn't need to change virsh too.
It's a trade off. If using the configuration option you need to plan
in advance the fact you will be dumping compressed core, if you expose
it at the API level itself, you can activate it anytime, and that may be
more useful for example when interacting with a customer facing an
issue needing debug. So both ways are acceptable to me.
IMHO, we should follow the same style for save/restore and core dump.
As you say save/restore setup compression in qemu.conf & we should
do the same for core dump, allowing all the same formats. Compression
is the kind of thing you just want enabled all the time. I don't see
anyone who is going to pick & choose different compression algorithms
per API call, so exposing all the compression methods is just using
up a significant portion of the flag space for little real world gain.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:48 p.m.
On Thu, 21 Oct 2010 10:26:42 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
On Thu, Oct 21, 2010 at 10:35:10AM +0200, Daniel Veillard wrote:
> On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
> >
> > Now, virsh dump doesn't support compresses dump.
> > This patch adds GZIP and LZOP option to virsh dump and support
> > it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
> >
> > When I did 4G guest dump,
> > (Raw) 3844669750
> > (Gzip) 1029846577
> > (LZOP) 1416263880 (faster than gzip in general)
> >
> > This will be a help for a host where crash-dump is used
> > and several guests works on it.
> >
> > help message is modified as this.
> > NAME
> > dump - dump the core of a domain to a file for analysis
> >
> > SYNOPSIS
> > dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
> >
> > DESCRIPTION
> > Core dump a domain.
> >
> > OPTIONS
> > --live perform a live core dump if supported
> > --crash crash the domain after core dump
> > --gzip gzip dump(only one compression allowed
> > --lzop lzop dump(only one compression allowed
> > [--domain] <string> domain name, id or uuid
> > [--file] <string> where to dump the core
> >
> > Tested on Fedora-13+x86-64.
> >
> > Note: for better compression, we may have to skip pages filled by
> > zero or freed pages. But it seems it's qemu's works.
>
> The patch looks relatively simple and clean, I still have one comemnt
> below though. It also seems to me that any use of the dump need a follow
> up decompression before it can be fed to debug tools (gdb ...) as I
> don't think they handle compressed dumps natively.
>
> The other comment on principle about this patch is that for saving
> compression we use a qemu.conf option, maybe we should instead use
> a new option there for core compression, or simply reuse the same
> option for both (core being just a special kind of save). You will
> also note that save_image_format takes more options than lzop or gzip.
> If doing so one doesn't need to change virsh too.
>
> It's a trade off. If using the configuration option you need to plan
> in advance the fact you will be dumping compressed core, if you expose
> it at the API level itself, you can activate it anytime, and that may be
> more useful for example when interacting with a customer facing an
> issue needing debug. So both ways are acceptable to me.
IMHO, we should follow the same style for save/restore and core dump.
As you say save/restore setup compression in qemu.conf & we should
do the same for core dump, allowing all the same formats. Compression
is the kind of thing you just want enabled all the time. I don't see
anyone who is going to pick & choose different compression algorithms
per API call, so exposing all the compression methods is just using
up a significant portion of the flag space for little real world gain.
IMHO, hibernation(save vm) and coredump has big difference in usage.
Hibernation is a planned one and the system schedules disk space for it.
Coredump is not a planned one and the system has some special area for coredump.
(At least, most of crashdump user has specail disk space for crashdump.)
Usage is not the same and purpose is, either.
1. Assume a case: hibernation use gzip and coredump use "raw"
Hibernation can be slow because it's scheduled one.
Coredump must be fast because the user has to bring the guest up ASAP.
2. Assume a case: hibernation use raw and coredump uses lzop.
A user want to hibernation quickly. But at coredump, the user uses cluster-fail-over
and coredump itself is not need to be fast but disk-space for crashdump
seems to be small.
There are real gain, I think. But ok, if "flag" space is important, I'd like
to
only support lzop. Is it ok ?
Thanks,
-Kame
12:21 a.m.
On Fri, 22 Oct 2010 12:48:38 +0900
KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
On Thu, 21 Oct 2010 10:26:42 +0100
"Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> On Thu, Oct 21, 2010 at 10:35:10AM +0200, Daniel Veillard wrote:
> > On Thu, Oct 21, 2010 at 12:02:11PM +0900, KAMEZAWA Hiroyuki wrote:
> > >
> > > Now, virsh dump doesn't support compresses dump.
> > > This patch adds GZIP and LZOP option to virsh dump and support
> > > it at qemu coredump. (AFAIK, LZOP is available on RHEL6.)
> > >
> > > When I did 4G guest dump,
> > > (Raw) 3844669750
> > > (Gzip) 1029846577
> > > (LZOP) 1416263880 (faster than gzip in general)
> > >
> > > This will be a help for a host where crash-dump is used
> > > and several guests works on it.
> > >
> > > help message is modified as this.
> > > NAME
> > > dump - dump the core of a domain to a file for analysis
> > >
> > > SYNOPSIS
> > > dump [--live] [--crash] [--gzip] [--lzop] <domain> <file>
> > >
> > > DESCRIPTION
> > > Core dump a domain.
> > >
> > > OPTIONS
> > > --live perform a live core dump if supported
> > > --crash crash the domain after core dump
> > > --gzip gzip dump(only one compression allowed
> > > --lzop lzop dump(only one compression allowed
> > > [--domain] <string> domain name, id or uuid
> > > [--file] <string> where to dump the core
> > >
> > > Tested on Fedora-13+x86-64.
> > >
> > > Note: for better compression, we may have to skip pages filled by
> > > zero or freed pages. But it seems it's qemu's works.
> >
> > The patch looks relatively simple and clean, I still have one comemnt
> > below though. It also seems to me that any use of the dump need a follow
> > up decompression before it can be fed to debug tools (gdb ...) as I
> > don't think they handle compressed dumps natively.
> >
> > The other comment on principle about this patch is that for saving
> > compression we use a qemu.conf option, maybe we should instead use
> > a new option there for core compression, or simply reuse the same
> > option for both (core being just a special kind of save). You will
> > also note that save_image_format takes more options than lzop or gzip.
> > If doing so one doesn't need to change virsh too.
> >
> > It's a trade off. If using the configuration option you need to plan
> > in advance the fact you will be dumping compressed core, if you expose
> > it at the API level itself, you can activate it anytime, and that may be
> > more useful for example when interacting with a customer facing an
> > issue needing debug. So both ways are acceptable to me.
>
> IMHO, we should follow the same style for save/restore and core dump.
> As you say save/restore setup compression in qemu.conf & we should
> do the same for core dump, allowing all the same formats. Compression
> is the kind of thing you just want enabled all the time. I don't see
> anyone who is going to pick & choose different compression algorithms
> per API call, so exposing all the compression methods is just using
> up a significant portion of the flag space for little real world gain.
IMHO, hibernation(save vm) and coredump has big difference in usage.
Hibernation is a planned one and the system schedules disk space for it.
Coredump is not a planned one and the system has some special area for coredump.
(At least, most of crashdump user has specail disk space for crashdump.)
Usage is not the same and purpose is, either.
I discussed my team and decied to start from save_image_format qemu.conf.
Or I'll add dump_image_format configuration in qemu.conf
Thanks,
-Kame
4:41 a.m.
New subject: [libvirt] [PATCH v2 1/2] support compressed crashdump of guests
Thank you for advices for v1. This version adss dump_image_format config
for qemu.conf. 1/2 adds dump_image_format, 2/2 adds the check for availability of
compression program for save_image_format and dump_image_format.
==
Add dump_image_format[] to qemu.conf and support compressed dump
at virsh dump. coredump compression is important for saving disk space
in an environment where multiple guest run.
(In general, "disk space for dump" is specially allocated and will be
a dead space in the system. It's used only at emergency. So, it's better
to have both of save_image_format and dump_image_format. "save" is done
in scheduled manner with enough calculated disk space for it.)
This code reuses some of save_image_format[] and supports the same format
with virsh save.
---
src/qemu/qemu.conf | 4 ++++
src/qemu/qemu_conf.c | 11 +++++++++++
src/qemu/qemu_conf.h | 1 +
src/qemu/qemu_driver.c | 30 +++++++++++++++++++++++++-----
4 files changed, 41 insertions(+), 5 deletions(-)
Index: libvirt-0.8.4/src/qemu/qemu_conf.c
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_conf.c
+++ libvirt-0.8.4/src/qemu/qemu_conf.c
@@ -324,6 +324,17 @@ int qemudLoadDriverConfig(struct qemud_d
}
}
+ p = virConfGetValue (conf, "dump_image_format");
+ CHECK_TYPE ("dump_image_format", VIR_CONF_STRING);
+ if (p && p->str) {
+ VIR_FREE(driver->dumpImageFormat);
+ if (!(driver->dumpImageFormat = strdup(p->str))) {
+ virReportOOMError();
+ virConfFree(conf);
+ return -1;
+ }
+ }
+
p = virConfGetValue (conf, "hugetlbfs_mount");
CHECK_TYPE ("hugetlbfs_mount", VIR_CONF_STRING);
if (p && p->str) {
Index: libvirt-0.8.4/src/qemu/qemu_conf.h
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_conf.h
+++ libvirt-0.8.4/src/qemu/qemu_conf.h
@@ -159,6 +159,7 @@ struct qemud_driver {
virSecurityDriverPtr securitySecondaryDriver;
char *saveImageFormat;
+ char *dumpImageFormat;
pciDeviceList *activePciHostdevs;
Index: libvirt-0.8.4/src/qemu/qemu.conf
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu.conf
+++ libvirt-0.8.4/src/qemu/qemu.conf
@@ -144,7 +144,11 @@
# saving a domain in order to save disk space; the list above is in descending
# order by performance and ascending order by compression ratio.
#
+# save_image_format is used when you use 'virsh save' at scheduled saving.
+# dump_image_format is used when you use 'virsh dump' at emergency crashdump.
+#
# save_image_format = "raw"
+# dump_image_format = "raw"
# If provided by the host and a hugetlbfs mount point is configured,
# a guest may request huge page backing. When this mount point is
Index: libvirt-0.8.4/src/qemu/qemu_driver.c
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_driver.c
+++ libvirt-0.8.4/src/qemu/qemu_driver.c
@@ -5716,11 +5716,15 @@ static int qemudDomainCoreDump(virDomain
int resume = 0, paused = 0;
int ret = -1, fd = -1;
virDomainEventPtr event = NULL;
- const char *args[] = {
- "cat",
- NULL,
- };
+ int compress;
qemuDomainObjPrivatePtr priv;
+ /*
+ * We reuse "save" flag for "dump" here. Then, we can support the
same
+ * format in "save" and "dump".
+ */
+ compress = QEMUD_SAVE_FORMAT_RAW;
+ if (driver->dumpImageFormat)
+ compress = qemudSaveCompressionTypeFromString(driver->dumpImageFormat);
qemuDriverLock(driver);
vm = virDomainFindByUUID(&driver->domains, dom->uuid);
@@ -5787,9 +5791,25 @@ static int qemudDomainCoreDump(virDomain
}
qemuDomainObjEnterMonitorWithDriver(driver, vm);
- ret = qemuMonitorMigrateToFile(priv->mon,
+ if (compress == QEMUD_SAVE_FORMAT_RAW) {
+ const char *args[] = {
+ "cat",
+ NULL,
+ };
+ ret = qemuMonitorMigrateToFile(priv->mon,
QEMU_MONITOR_MIGRATE_BACKGROUND,
args, path, 0);
+ } else {
+ const char *prog = qemudSaveCompressionTypeToString(compress);
+ const char *args[] = {
+ prog,
+ "-c",
+ NULL,
+ };
+ ret = qemuMonitorMigrateToFile(priv->mon,
+ QEMU_MONITOR_MIGRATE_BACKGROUND,
+ args, path, 0);
+ }
qemuDomainObjExitMonitorWithDriver(driver, vm);
if (ret < 0)
goto endjob;
4:42 a.m.
New subject: [libvirt] [PATCH v2 2/2] check compression program is available at config
At compression, external programs are used but it is not checked whether
the program is available or not.
Check it at parsing qemu.conf and find problems in early stage.
---
src/qemu/qemu_conf.c | 46 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 39 insertions(+), 7 deletions(-)
Index: libvirt-0.8.4/src/qemu/qemu_conf.c
===================================================================
--- libvirt-0.8.4.orig/src/qemu/qemu_conf.c
+++ libvirt-0.8.4/src/qemu/qemu_conf.c
@@ -316,22 +316,54 @@ int qemudLoadDriverConfig(struct qemud_d
p = virConfGetValue (conf, "save_image_format");
CHECK_TYPE ("save_image_format", VIR_CONF_STRING);
if (p && p->str) {
- VIR_FREE(driver->saveImageFormat);
- if (!(driver->saveImageFormat = strdup(p->str))) {
- virReportOOMError();
- virConfFree(conf);
- return -1;
- }
+ int find = 1;
+ if (strcmp(p->str, "raw")) {
+ char *c;
+ c = virFindFileInPath(p->str);
+ if (!c)
+ find = 0;
+ else
+ VIR_FREE(c);
+ }
+ VIR_FREE(driver->saveImageFormat);
+ if (find) {
+ if (!(driver->saveImageFormat = strdup(p->str))) {
+ virReportOOMError();
+ virConfFree(conf);
+ return -1;
+ }
+ } else {
+ qemuReportError(VIR_ERR_INTERNAL_ERROR,
+ "save_image_format cannot find program %s", p->str);
+ virConfFree(conf);
+ return -1;
+ }
}
p = virConfGetValue (conf, "dump_image_format");
CHECK_TYPE ("dump_image_format", VIR_CONF_STRING);
if (p && p->str) {
+ int find = 1;
+ if (strcmp(p->str, "raw")) {
+ char *c;
+ c = virFindFileInPath(p->str);
+ if (!c)
+ find = 0;
+ else
+ VIR_FREE(c);
+ }
VIR_FREE(driver->dumpImageFormat);
- if (!(driver->dumpImageFormat = strdup(p->str))) {
+ if (find) {
+ if (!(driver->dumpImageFormat = strdup(p->str))) {
virReportOOMError();
virConfFree(conf);
return -1;
+ }
+ } else {
+ qemuReportError(VIR_ERR_INTERNAL_ERROR,
+ "dump_image_format cannot find program %s", p->str);
+ virConfFree(conf);
+ return -1;
}
}
5147
days inactive
5148
days old
7 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
KAMEZAWA Hiroyuki