RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1056982 - win2008.x86_64 guest BSOD on AMD (error code:0x19, BAD_POOL_HEADER)
Summary: win2008.x86_64 guest BSOD on AMD (error code:0x19, BAD_POOL_HEADER)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Radim Krčmář
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1003751 1038594 1038902 1049800 1049823 (view as bug list)
Depends On:
Blocks: 1069309
TreeView+ depends on / blocked
 
Reported: 2014-01-23 09:53 UTC by CongLi
Modified: 2014-06-18 06:50 UTC (History)
20 users (show)

Fixed In Version: kernel-3.10.0-111.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:06:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
mem_dump debug info (4.81 KB, text/plain)
2014-01-23 09:53 UTC, CongLi
no flags Details
QEMU CML (2.18 KB, text/plain)
2014-02-10 09:22 UTC, CongLi
no flags Details
list of commits from 1.5.2-4 to 1.5.3-2 (5.66 KB, text/plain)
2014-03-03 15:09 UTC, Paolo Bonzini
no flags Details
strace-kernel_irqchip_off.txt (1.14 MB, application/x-xz)
2014-03-04 05:42 UTC, CongLi
no flags Details
strace-kernel_irqchip_on.txt (536.28 KB, application/x-xz)
2014-03-04 05:43 UTC, CongLi
no flags Details

Description CongLi 2014-01-23 09:53:06 UTC
Created attachment 854272 [details]
mem_dump debug info

Description of problem:
win2008.x86_64 guest BSOD (error code:0x19, BAD_POOL_HEADER)

Version-Release number of selected component (if applicable):
kernel-3.10.0-78.el7.x86_64
qemu-kvm-rhev-1.5.3-39.el7.x86_64
virtio-win-prewhql-0.1-74.iso

How reproducible:
sometimes

Steps to Reproduce:
1. Boot up a win2008.x86_64 guest w/ virtio-blk driver
2.
3.

Actual results:
win2008.x86_64 guest BSOD (error code:0x19, BAD_POOL_HEADER)

Expected results:
win2008.x86_64 guest boot up successfully

Additional info:
1. debug info (attached the debug file):
3: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffff8800516f960, The pool entry we were looking for within the page.
Arg3: fffff8800516f980, The next pool entry.
Arg4: 0000000005020104, (reserved)

2. QEMU CML:
/home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
    -S  \
    -name 'virt-tests-vm1'  \
    -sandbox off  \
    -M pc-q35-rhel7.0.0  \
    -nodefaults  \
    -vga qxl  \
    -global qxl-vga.vram_size=33554432 \
    -device intel-hda,bus=pcie.0,addr=02 \
    -device hda-duplex  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1-20140123-061140-yyUhRN3I,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=serial_id_serial0,path=/tmp/serial-serial0-20140123-061140-yyUhRN3I,server,nowait \
    -device isa-serial,chardev=serial_id_serial0 \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pcie.0,addr=03  \
    -chardev socket,id=devvs,path=/tmp/virtio_port-vs-20140123-061140-yyUhRN3I,server,nowait \
    -device virtserialport,chardev=devvs,name=vs,id=vs,bus=virtio_serial_pci0.0  \
    -chardev socket,id=seabioslog_id_20140123-061140-yyUhRN3I,path=/tmp/seabios-20140123-061140-yyUhRN3I,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20140123-061140-yyUhRN3I,iobase=0x402 \
    -device nec-usb-xhci,id=usb1,bus=pcie.0,addr=04 \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pcie.0,addr=05 \
    -device virtio-net-pci,mac=9a:c5:c6:c7:c8:c9,id=id1nehRf,netdev=idvFTXW0,bus=pcie.0,addr=06  \
    -netdev tap,id=idvFTXW0,vhost=on  \
    -m 4096  \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2  \
    -cpu 'Opteron_G4',+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic \
    -drive id=drive_cd1,if=none,snapshot=off,aio=native,media=cdrom,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/isos/windows/winutils.iso \
    -device ide-cd,id=cd1,drive=drive_cd1,bootindex=1,bus=ide.0,unit=0 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -spice port=3000,password=123456,addr=0,tls-port=3200,x509-dir=/tmp/spice_x509d,tls-channel=main,tls-channel=inputs,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off \
    -enable-kvm \
    -monitor stdio

3. When I do system_reset to guest, always generate BSOD w/ different error code.
   There are the related bugs:
   1. Bug 1049800 - win2008.x86_64 guest BSOD (error code:0x50, PAGE_FAULT_IN_NONPAGED_AREA)
   2. Bug 1038594 - Win2008 x86_64 BSOD(0x0A) on the starting of OS
   3. Bug 1038902 - Win2008 BSOD on OS booting(0x7e and 0xc5)
   4. Bug 1049823 - win2008.x86_64 guest BSOD (error code:0x3B, SYSTEM_SERVICE_EXCEPTION) 

4. processor	: 23
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 1
model name	: AMD Opteron(TM) Processor 6234                 
stepping	: 2
microcode	: 0x6000626
cpu MHz		: 2400.032
cache size	: 2048 KB
physical id	: 1
siblings	: 12
core id		: 5
cpu cores	: 6
apicid		: 75
initial apicid	: 43
fpu		: yes
fpu_exception	: yes
cpuid level	: 13
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bogomips	: 4799.74
TLB size	: 1536 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb

Comment 2 CongLi 2014-01-23 10:05:55 UTC
1. qemu-img check /home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-virtio.qcow2

No errors were found on the image.
166193/491520 = 33.81% allocated, 4.31% fragmented, 0.00% compressed clusters
Image end offset: 10893787136

2. qemu-img info /home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-virtio.qcow2

image: /home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-virtio.qcow2
file format: qcow2
virtual size: 30G (32212254720 bytes)
disk size: 10G
cluster_size: 65536
Format specific information:
    compat: 0.10

Comment 4 Ronen Hod 2014-01-28 13:21:13 UTC
Hi,

It is not clear what the disk size is. It says 10G, but also "166193/491520 = 33.81% allocated". 491,520 does not match with 10G.
And if the memory size is 30G, then it is recommended to have a larger disk.
And q35 is in tech-preview for 7.0
Need to isolate, which of those (if any) is the issue.

Thanks.

Comment 5 juzhang 2014-02-07 01:19:19 UTC
Hi Cong,

Could you have a look comment4 and update the testing result?

Best Regards,
Junyi

Comment 8 CongLi 2014-02-10 09:22:04 UTC
Created attachment 861292 [details]
QEMU CML

Comment 10 Andrew Jones 2014-02-11 10:01:16 UTC
Since the BSOD changes crash to crash, then I have a feeling that Windows goes off in the weeds, and there would be nothing to gain from wading through a bunch of assembly code trying to find out what the guest was doing at the time. We'll need to add tracing to the host side in order to find the problem. To do that, we need to reduce the amount of code we trace. To get that reduction we need a very minimal guest config that still reproduces the issue.

A while back I asked that we create a bare minimal qemu command line that we can use as a basis for config option isolation. This command line could possibly even configure a guest that has no disk and no nic, just a cdrom to boot the installer off (which of course would eventually complain about the lack of a disk, but for early boot problems we don't care). Do we have that super minimal command line constructed yet? If so, does this problem reproduce with such a minimal command line? If the guest can boot with a minimal command line, then can we add each option, one at at time, until we find the device that introduces this bug? Once we know what that is we can start tracing the qemu and kvm wrt to the code paths that device uses.

Comment 11 CongLi 2014-02-12 02:14:30 UTC
(In reply to Andrew Jones from comment #10)

Hi Andrew,

From the mail we talked, here are the questions which need to test:

1. Was another exactly identical host (Opteron_G?), but not the same
exact machine, ever tried?

2. Are all 5-6 bugs on the same exact host? do non win2008 guests work?

3. The CML is too large and complex. We need to reduce the command line
down to a minimal reproducer. See my comment

https://bugzilla.redhat.com/show_bug.cgi?id=1056982#c10

4. is this a regression? 
   or, conversely, does the problem still reproduce using
   the latest kernel and qemu? (probably not, because rhel7
   isn't far off the latest, but it's still worth trying if the
   issue isn't a regression).

I will have a test about the above questions, and if there is other question to test, feel free to ask me.

Thanks,
Cong

Comment 12 CongLi 2014-02-12 08:26:51 UTC
(In reply to CongLi from comment #11)

To make sure the image is good, I have boot and done many times' 'system_reset' to the win2008.x86_64 guest on a intel machine, the test result is good. 

> 1. Was another exactly identical host (Opteron_G?), but not the same
> exact machine, ever tried?

  Yes, it can be reproduced on another exactly identical host as comment 0.
  And also can be reproduced on machine:
processor	: 3
vendor_id	: AuthenticAMD
cpu family	: 21
model		: 16
model name	: AMD A10-5800K APU with Radeon(tm) HD Graphics  
  but not all AMD hosts can hit this problem.

> 2. Are all 5-6 bugs on the same exact host? do non win2008 guests work?
  
    2.1 Not sure whether all these bugs are on the same host for some aren't reported by me and there is no host info in the bug, but those which I reported are the same host.
    2.2 didn't hit this bug with guest win2008.i386, win7(i386, x86_64), win8.0(i386, x86_64), win8.1(i386, x86_64)

> 3. The CML is too large and complex. We need to reduce the command line
> down to a minimal reproducer. See my comment
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1056982#c10

This bug can be reproduced w/ the following CML:
/home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \
    -monitor stdio \
    -vnc :0 \
    -m 4096  \

> 4. is this a regression? 
>    or, conversely, does the problem still reproduce using
>    the latest kernel and qemu? (probably not, because rhel7
>    isn't far off the latest, but it's still worth trying if the
>    issue isn't a regression).

    4.1 No, it's not a regression.
        I have downgraded qemu to qemu-kvm-1.5.3-10.el7.x86_64, kernel to kernel-3.10.0-35.el7.x86_64, still hit this bug.
         
    4.2 Yes, this problem still existed on the following version, and the above results are tested on the version:
      kernel-3.10.0-85.el7.x86_64
      qemu-kvm-1.5.3-45.el7.x86_64

Thanks,
Cong

Comment 13 Andrew Jones 2014-02-12 14:52:17 UTC
(In reply to CongLi from comment #12)
> (In reply to CongLi from comment #11)

Thanks for the quick reply.

> 
> To make sure the image is good, I have boot and done many times'
> 'system_reset' to the win2008.x86_64 guest on a intel machine, the test
> result is good. 
> 
> > 1. Was another exactly identical host (Opteron_G?), but not the same
> > exact machine, ever tried?
> 
>   Yes, it can be reproduced on another exactly identical host as comment 0.
>   And also can be reproduced on machine:
> processor	: 3
> vendor_id	: AuthenticAMD
> cpu family	: 21
> model		: 16
> model name	: AMD A10-5800K APU with Radeon(tm) HD Graphics  
>   but not all AMD hosts can hit this problem.

OK, good to know.

> 
> > 2. Are all 5-6 bugs on the same exact host? do non win2008 guests work?
>   
>     2.1 Not sure whether all these bugs are on the same host for some aren't
> reported by me and there is no host info in the bug, but those which I
> reported are the same host.
>     2.2 didn't hit this bug with guest win2008.i386, win7(i386, x86_64),
> win8.0(i386, x86_64), win8.1(i386, x86_64)

Also good to know.

> 
> > 3. The CML is too large and complex. We need to reduce the command line
> > down to a minimal reproducer. See my comment
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1056982#c10
> 
> This bug can be reproduced w/ the following CML:
> /home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
>     -drive
> id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/staf-
> kvm-devel/autotest-devel/client/tests/virt/shared/data/images/win2008-64-
> virtio.qcow2 \
>     -device
> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \
>     -monitor stdio \
>     -vnc :0 \
>     -m 4096  \

This is a nicely reduced command line. Thanks for this.

> 
> > 4. is this a regression? 
> >    or, conversely, does the problem still reproduce using
> >    the latest kernel and qemu? (probably not, because rhel7
> >    isn't far off the latest, but it's still worth trying if the
> >    issue isn't a regression).
> 
>     4.1 No, it's not a regression.
>         I have downgraded qemu to qemu-kvm-1.5.3-10.el7.x86_64, kernel to
> kernel-3.10.0-35.el7.x86_64, still hit this bug.

I was actually thinking about checking for a regression since rhel6. The version numbers tested here don't have a very big delta.

>          
>     4.2 Yes, this problem still existed on the following version, and the
> above results are tested on the version:
>       kernel-3.10.0-85.el7.x86_64
>       qemu-kvm-1.5.3-45.el7.x86_64
> 

I was thinking about testing the absolute latest, but as I said before the chance that it will have recently been magically fixed is pretty small, so no need for that test.

I can now begin reproducing the bug with some tracing enabled on the host side. Can I get access to a host where it reproduces and has a windows image that it reproduces with?

Thanks,
drew

Comment 16 CongLi 2014-02-18 05:21:04 UTC
(In reply to Andrew Jones from comment #13)

> > > 4. is this a regression? 
> > >    or, conversely, does the problem still reproduce using
> > >    the latest kernel and qemu? (probably not, because rhel7
> > >    isn't far off the latest, but it's still worth trying if the
> > >    issue isn't a regression).
> > 
> >     4.1 No, it's not a regression.
> >         I have downgraded qemu to qemu-kvm-1.5.3-10.el7.x86_64, kernel to
> > kernel-3.10.0-35.el7.x86_64, still hit this bug.
> 
> I was actually thinking about checking for a regression since rhel6. The
> version numbers tested here don't have a very big delta.

Not met this bug on RHEL.6.6 host w/ the same machine in comment 0.

kernel-2.6.32-444.el6.x86_64 
qemu-kvm-rhev-0.12.1.2-2.420.el6.x86_64

Comment 17 CongLi 2014-02-26 10:32:54 UTC
Tested on the following version:
kernel-3.10.0-95.el7.x86_64
seabios-1.7.2.2-11.el7.x86_64

1. qemu-kvm-1.5.3-2.el7  -->  fail

2. qemu-kvm-1.5.2-1.el7  -->  pass
   qemu-kvm-1.5.2-4.el7  -->  pass

Use the guest which is BSOD on qemu-kvm-1.5.3-2.el7, can boot up successfully with qemu-kvm-1.5.2-4.el7, as well do system_reset.

And I can't get qemu-kvm-1.5.3-1.el7 for it is deleted in brew, but I guess this bug was introduced from qemu-kvm-1.5.3, and I found qemu-kvm-1.5.3.1 has rebase.

QEMU CML:
/usr/libexec/qemu-kvm \
-drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=/home/win2008-64-virtio.qcow2 \
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \
-monitor stdio \
-vnc :0 \
-m 4096  \

Comment 18 Paolo Bonzini 2014-03-03 15:09:06 UTC
Created attachment 869957 [details]
list of commits from 1.5.2-4 to 1.5.3-2

CongLi, how can you be sure that qemu-kvm-1.5.2 works if the bug is only reproduced sometimes?

In any case, I rebuilt qemu-kvm-1.5.3-1.el7 here:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7132551

Please test with it.

I attach the list of patches between 1.5.2-4 and 1.5.3-2.  The only ones that remotely could cause the failure are

pc: Haswell doesn't have rdtscp on rhel6.x
pc: SandyBridge rhel6.x compat fixes
pc: Remove PCLMULQDQ from Westmere on rhel6.x machine-types
pc: set compat CPUID[0x80000001].EDX bits on Westmere for rhel6.x
pc: rhel6.x has x2apic present on Conroe/Penryn/Nehalem CPU models
pc: Remove incorrect rhel6.x compat "model" value for Conroe/Penryn/Nehalem
pc: set level/xlevel correctly on 486/qemu32 CPU models for rhel6.x

Comment 22 CongLi 2014-03-04 05:21:23 UTC
(In reply to Paolo Bonzini from comment #18)

> In any case, I rebuilt qemu-kvm-1.5.3-1.el7 here:
> http://brewweb.devel.redhat.com/brew/taskinfo?taskID=7132551
> 
> Please test with it.

qemu-kvm-1.5.3-1.el7  --> pass

qemu-kvm-1.5.3-2.el7  --> fail

As Radim said, this bug is caused by '-machine kernel_irqchip=on|off'.

qemu-kvm-1.5.3-2.el7:

1. -machine kernel_irqchip=on   -->  fail (BSOD)
2. -machine kernel_irqchip=off  -->  pass

CML:
/home/staf-kvm-devel/autotest-devel/client/tests/virt/qemu/qemu \
-drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=win2008-64-virtio.qcow2 \
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \
-monitor stdio \
-vnc :0 \
-m 4096  \
-machine kernel_irqchip=on

Will attach the strace log later.
1. -machine kernel_irqchip=on:  quit directly when met BSOD
2. -machine kernel_irqchip=off: guest boot successfully

Comment 23 CongLi 2014-03-04 05:42:33 UTC
Created attachment 870243 [details]
strace-kernel_irqchip_off.txt

Comment 24 CongLi 2014-03-04 05:43:11 UTC
Created attachment 870244 [details]
strace-kernel_irqchip_on.txt

Comment 33 Karen Noel 2014-03-11 22:22:10 UTC
Posted upstream:
http://comments.gmane.org/gmane.linux.kernel/1664960

Comment 40 Jarod Wilson 2014-03-17 18:20:04 UTC
Patch(es) available on kernel-3.10.0-111.el7

Comment 44 Yvugenfi@redhat.com 2014-03-18 13:15:26 UTC
*** Bug 1038594 has been marked as a duplicate of this bug. ***

Comment 45 Yvugenfi@redhat.com 2014-03-18 13:16:11 UTC
*** Bug 1038902 has been marked as a duplicate of this bug. ***

Comment 46 Yvugenfi@redhat.com 2014-03-18 13:19:00 UTC
*** Bug 1049800 has been marked as a duplicate of this bug. ***

Comment 47 Yvugenfi@redhat.com 2014-03-18 13:19:09 UTC
*** Bug 1049823 has been marked as a duplicate of this bug. ***

Comment 48 CongLi 2014-03-19 10:09:13 UTC
Tested on:
qemu-kvm-rhev-1.5.3-53.el7.x86_64

1. Reproduce this bug on kernel-3.10.0-110.el7.x86_64
dafault=on                  -->  fail
-machine kernel_irqchip=on  -->  fail
-machine kernel_irqchip=off -->  pass

2. Verify this bug on kernel-3.10.0-112.el7.x86_64
dafault=on                  -->  pass
-machine kernel_irqchip=on  -->  pass
-machine kernel_irqchip=off -->  pass

CML:
/usr/libexec/qemu-kvm \
-drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,file=win2008-64-virtio.qcow2 \
-device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=05 \
-monitor stdio \
-vnc :0 \
-m 4096  \

As the above info, we could set the status to 'VERIFIED'.

Comment 49 juzhang 2014-03-19 10:19:51 UTC
According to comment43 and comment48, set this issue as verified.

Comment 50 Karen Noel 2014-03-25 14:09:33 UTC
*** Bug 1003751 has been marked as a duplicate of this bug. ***

Comment 51 Ludek Smid 2014-06-13 12:06:31 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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