[libvirt] [PATCH] Make guest OS bootable when hardware failure happens in log disk
[Problem] Currently, guest OS's messages can be logged to a local disk of host OS by creating chadevs with options below. -chardev file,id=charserial0,path=<log file's path> -device isa-serial,chardev=chardevserial0,id=serial0 When a hardware failure happens in the disk, qemu-kvm can't create the chardevs. In this case, guest OS doesn't boot up. Actually, there are users who don't desire that guest OS goes down due to a hardware failure of a log disk only.Therefore, libvirt should offer some way to boot guest OS up even if the log disk is broken. [Solution] This patch changes a destination to /dev/null in case a log file can't be opened. Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> --- src/qemu/qemu_process.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 8c4bfb7..fdf26ad 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2440,7 +2440,25 @@ qemuProcessPrepareChardevDevice(virDomainDefPtr def ATTRIBUTE_UNUSED, virReportSystemError(errno, _("Unable to pre-create chardev file '%s'"), dev->source.data.file.path); - return -1; + VIR_FREE(dev->source.data.file.path); + /* + * Change a destination to /dev/null to boot guest OS up + * even if a log disk is broken. + */ + dev->source.data.file.path = strdup("/dev/null"); + + if (!dev->source.data.file.path) { + virReportOOMError(); + return -1; + } + + if ((fd = open(dev->source.data.file.path, + O_CREAT | O_APPEND, S_IRUSR|S_IWUSR)) < 0) { + virReportSystemError(errno, + _("Unable to pre-create chardev file '%s'"), + dev->source.data.file.path); + return -1; + } } VIR_FORCE_CLOSE(fd); -- 1.7.1
On Fri, Apr 05, 2013 at 02:36:45PM +0000, Seiji Aguchi wrote:
[Problem] Currently, guest OS's messages can be logged to a local disk of host OS by creating chadevs with options below. -chardev file,id=charserial0,path=<log file's path> -device isa-serial,chardev=chardevserial0,id=serial0
When a hardware failure happens in the disk, qemu-kvm can't create the chardevs. In this case, guest OS doesn't boot up.
Actually, there are users who don't desire that guest OS goes down due to a hardware failure of a log disk only.Therefore, libvirt should offer some way to boot guest OS up even if the log disk is broken.
[Solution] This patch changes a destination to /dev/null in case a log file can't be opened.
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> --- src/qemu/qemu_process.c | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 8c4bfb7..fdf26ad 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -2440,7 +2440,25 @@ qemuProcessPrepareChardevDevice(virDomainDefPtr def ATTRIBUTE_UNUSED, virReportSystemError(errno, _("Unable to pre-create chardev file '%s'"), dev->source.data.file.path); - return -1; + VIR_FREE(dev->source.data.file.path); + /* + * Change a destination to /dev/null to boot guest OS up + * even if a log disk is broken. + */ + dev->source.data.file.path = strdup("/dev/null"); + + if (!dev->source.data.file.path) { + virReportOOMError(); + return -1; + } + + if ((fd = open(dev->source.data.file.path, + O_CREAT | O_APPEND, S_IRUSR|S_IWUSR)) < 0) { + virReportSystemError(errno, + _("Unable to pre-create chardev file '%s'"), + dev->source.data.file.path); + return -1; + } }
NACK this is putting inappropriate policy decisions into libvirt. This may be how you want this scenario to work, but it is certainly not what every user of libvirt will want. If the storage is fubar & the management application wants to still start the guest, they should change the XML config appropriately. REgards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
NACK this is putting inappropriate policy decisions into libvirt. This may be how you want this scenario to work, but it is certainly not what every user of libvirt will want.
How about adding some option to libvirt so that the users can choose policies?
If the storage is fubar & the management application wants to still start the guest, they should change the XML config appropriately.
I think that providing options is user-friendly rather than asking users to edit xml by hand after the storage is broken. Seiji
participants (2)
-
Daniel P. Berrange -
Seiji Aguchi