Bug 637351 - xend should check device_model before really creating the HVM guest
Summary: xend should check device_model before really creating the HVM guest
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.6
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Michal Novotny
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 514500
TreeView+ depends on / blocked
 
Reported: 2010-09-25 05:33 UTC by Lei Wang
Modified: 2014-02-02 22:38 UTC (History)
8 users (show)

Fixed In Version: xen-3.0.3-122.el5
Doc Type: Bug Fix
Doc Text:
When the device_model variable in a HVM guest configuration file was not properly specified, the qemu-dm daemon did not start; even though the virtual machine was created, its status reported by the "xm list" command was incorrect, and the machine could not be properly used. With this update, the device model is checked on domain startup and an error message is issued by the xend daemon if the device model is incorrect, thus preventing this bug.
Clone Of:
Environment:
Last Closed: 2011-07-21 09:15:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
xend.log (608.90 KB, text/plain)
2010-09-25 05:33 UTC, Lei Wang
no flags Details
seems no output in xm dmesg (4.77 KB, text/plain)
2010-09-25 05:34 UTC, Lei Wang
no flags Details
xm dmesg (11.38 KB, text/plain)
2010-09-25 05:55 UTC, Lei Wang
no flags Details
Patch to implement check for device model existence/executable bit (1.74 KB, patch)
2010-11-30 13:19 UTC, Michal Novotny
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1070 0 normal SHIPPED_LIVE xen bug fix and enhancement update 2011-07-21 09:12:56 UTC

Description Lei Wang 2010-09-25 05:33:44 UTC
Created attachment 449557 [details]
xend.log

Description of problem:
If device_model in HVM guest config file is not properly specified(like specify device_model="/usr/lib64/xen/bin/qemu-dm" on i386 host), the qemu-dm will not start up, though the vm will be created its status is confused, and actually the vm is unusable, it could be better if xend could check and report error before really creating the HVM guest.

Version-Release number of selected component (if applicable):
xen-3.0.3-116
kernel-xen-2.6.18-220

How reproducible:
Always

Steps to Reproduce:
1.on i386 host, edit a HVM config file, make device_model="/usr/lib64/xen/bin/qemu-dm"
(or on x86_64 host, make device_model="/usr/lib/xen/bin/qemu-dm")
2.create the HVM guest
3.check vm status by "xm list"
4.check vm console by virt-manager
5.check qemu-dm by "ps aux | grep qemu"
  
Actual results:
At step3, the vm status is confused.
[root@dhcp-93-192 config-file]# xm li
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     3358     2 r-----     69.8
rhel6.0-32-hvm                             1      511     1 ------      0.0
At step4, it said "Console is not yet active for guest"
At step5, no qemu-dm start up for the HVM guest.

Expected results:
If the device_model is not proper for the host arch, xend should report error before really create the HVM guest.

Comment 1 Lei Wang 2010-09-25 05:34:38 UTC
Created attachment 449558 [details]
seems no output in xm dmesg

Comment 2 Lei Wang 2010-09-25 05:54:56 UTC
Comment on attachment 449558 [details]
seems no output in xm dmesg

Forgot to add "loglvl=all guest_loglvl=all" to kernel command line, will reattach xm dmesg later.

Comment 3 Lei Wang 2010-09-25 05:55:54 UTC
Created attachment 449563 [details]
xm dmesg

Comment 4 Michal Novotny 2010-11-30 11:47:42 UTC
Well, this seems that the issue occurs when the binary doesn't exist or is not executable. For this reason a patch like:

diff --git a/tools/python/xen/xend/image.py b/tools/python/xen/xend/image.py
index 42619ee..19bb9f6 100644
--- a/tools/python/xen/xend/image.py
+++ b/tools/python/xen/xend/image.py
@@ -431,6 +431,8 @@ class HVMImageHandler(ImageHandler):
             env['XAUTHORITY'] = self.xauthority
         if self.vncconsole:
             args = args + ([ "-vncviewer" ])
+        if not os.access(self.device_model, os.X_OK):
+            raise VmError("Cannot spawn device model")
         log.info("spawning device models: %s %s", self.device_model, args)
         self.pid = os.spawnve(os.P_NOWAIT, self.device_model, args, env)
         self.vm.storeDom("image/device-model-pid", self.pid)

will be working fine.

Michal

Comment 5 Michal Novotny 2010-11-30 13:19:00 UTC
Created attachment 463724 [details]
Patch to implement check for device model existence/executable bit

This is the patch to check for the device model existence and execute permissions on domain startup. Without this patch applied the domain was in no state and connection to xenconsole was not possible although on the first sight the domain was running. With this patch applied it raises an error message that xend cannot spawn the device model instead of running the domain. The patch has been tested on
x86_64 dom0 and RHEL-6 HVM guest with valid and invalid (i.e. non-existing or not executable) device model and everything was working fine.

Michal

Comment 8 RHEL Program Management 2011-01-11 19:51:23 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 9 RHEL Program Management 2011-01-12 15:21:39 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 12 Yuyu Zhou 2011-03-17 13:10:18 UTC
Reproduce on xen-3.0.3-116.el5 and Verified on xen-3.0.3-122.el5

On xen-3.0.3-116.el5:
create hvm guest with wrong device model
# xm cr hvm.cfg 
Using config file "./hvm.cfg".
Started domain xen-hvm-guest
# xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     7390     4 r-----    129.9
xen-hvm-guest                              9      511     1 ------      0.0

On xen-3.0.3-122.el5:
# xm cr hvm.cfg 
Using config file "./hvm.cfg".
Error: Cannot spawn device model

So, change the Status to VERIFIED

Comment 13 Tomas Capek 2011-07-13 13:19:32 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When the device_model variable in a HVM guest configuration file was not properly specified, the qemu-dm daemon did not start; even though the virtual machine was created, its status reported by the "xm list" command was incorrect, and the machine could not be properly used. With this update, the device model is checked on domain startup and an error message is issued  by the xend daemon if the device model is incorrect, thus preventing this bug.

Comment 14 errata-xmlrpc 2011-07-21 09:15:12 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1070.html

Comment 15 errata-xmlrpc 2011-07-21 11:58:57 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1070.html


Note You need to log in before you can comment on or make changes to this bug.