This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 476911 - VMM sees storage while VM console does not
VMM sees storage while VM console does not
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen (Show other bugs)
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Xen Maintainance List
Martin Jenner
Depends On:
Blocks: 514491
  Show dependency treegraph
Reported: 2008-12-17 16:57 EST by Jim Evans
Modified: 2011-04-01 10:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-04-01 10:18:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
adding attachment (102.59 KB, application/x-zip-compressed)
2008-12-17 17:02 EST, Jim Evans
no flags Details
snapshot 6 vm console doesn't see new storage added (58.45 KB, image/x-png)
2008-12-19 12:56 EST, Jim Evans
no flags Details
hardware details sees new storage with snapshot 6 (51.66 KB, image/x-png)
2008-12-19 12:59 EST, Jim Evans
no flags Details

  None (edit)
Description Jim Evans 2008-12-17 16:57:41 EST
Description of problem: Difference seen between VMM and a VM console. The
attached screenshots show I do not see /dev/xvdb at the VM console but
I do see it at the VMM console. Only seen with a fully-virtualized RH5.3 VM.

Version-Release number of selected component (if applicable):
RHEL 5.3 snapshot 5

How reproducible:

Steps to Reproduce:
1. add a new virtual disk
2. fdisk -l doesn't see it
3. VMM does
Actual results:
Missing storage from console

Expected results:
I should see the new /dev/xvdb after an fdisk -l

Additional info: I was trying to catagorize this issue
when I stumbled upon Bug 476902. Since it was a different
issue I logged it as a separate bug. 

I did not see this with a para-virtualized RH5.3 VM or a second
fully-virtualized RH5.3 VM.
Comment 1 Jim Evans 2008-12-17 17:02:36 EST
Created attachment 327287 [details]
adding attachment

adding attachment that didn't make it in the initial listing
Comment 2 Bill Burns 2008-12-18 15:20:37 EST
Some issues with block attach/detach were fixed in snapshot fix. Can you please
retest with that and report back?
Comment 3 Jim Evans 2008-12-19 12:56:36 EST
Created attachment 327470 [details]
snapshot 6 vm console doesn't see new storage added
Comment 4 Jim Evans 2008-12-19 12:59:06 EST
Created attachment 327471 [details]
hardware details sees new storage with snapshot 6

HP has a mandatory shutdown for two weeks so I cannot provide any additional help. That and 12' of snow is about to hit the area. Sorry.
Comment 8 Chris Lalancette 2009-02-27 13:52:25 EST
     Can you give more details about what you saw here?  I think you tried to block-attach a new disk to a FV guest.  Is that the case?  Can you give me detailed steps of what exactly you did?  Also, what do you mean by "VMM"?  Note that block-attach will only work for FV guests iff you are running the PV-on-HVM drivers inside the guest, so that might explain the difference between your two FV guests.

Chris Lalancette
Comment 9 Jim Evans 2009-02-27 14:36:13 EST

If I recall, I added a LUN by the lvcreate command carving up an existing volume group in that VM.  

At this point I should have seen /dev/xvdb show up with fdisk -l but didn't

I was able to see xvdb show up on the Virtual Machine Display (an attachment) so the VMM/Virtual Machine Manager display presentation. (I always use the GUI and not the command line). To me the GUI/Virtual Machine Display for that VM showed the new storage but fdisk didn't.

I also have to say I don't recall seeing this issue since snapshot 6 two months ago but I also haven't focused that much on FV VMs either. 

Comment 11 Paolo Bonzini 2011-04-01 10:18:14 EDT
I strongly suspect that Jim wasn't using PV-on-HVM drivers.  Since there has been no activity since February 2009 I'm closing this bug.

Jim, feel free to reopen if you still see this bug.  In this case, please make sure to attach an sosreport of both the host and the guest.


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