config drive not visible to windows

Bug #1155842 reported by Brant Knudson
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Tony Yang
Grizzly
Fix Released
Medium
Matt Riedemann

Bug Description

When I boot a windows 2008 server image in libvirt/kvm with --config-drive True, the config drive isn't usable by the windows guest as far as I can tell.

I start with devstack, load a windows 2008 server image into glance, and boot it with an appropriately large flavor. When I go to "My Computer", only C: is available. "Disk Management" in "Server Manager" shows a Disk 0 (C:), and a Disk 1, which I assume is the config drive, but it's status is "Unknown/Not Initialized".

The XML for the domain looks shows the disk is presented to the guest:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/opt/stack/data/nova/instances/21499a0c-d65e-4d9b-9040-2a54edf10b1f/disk'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/opt/stack/data/nova/instances/21499a0c-d65e-4d9b-9040-2a54edf10b1f/disk.config'/>
      <target dev='vdz' bus='virtio'/>
      <alias name='virtio-disk25'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

I can mount the disk.config as an iso on the host linux system.

I expect that on Windows I'd be able to see a D: and be able to open it up and see the config drive files.

As another experiment, I tried setting config_drive_format = vfat in nova.conf. The result was pretty much the same but the drive showed up in "Disk Management" in "Server Manager" as "Basic/64 MB", but it still didn't show up as a D: drive.

The XML for the domain looks shows the disk is presented to the guest:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/opt/stack/data/nova/instances/a924026f-e3eb-4ecc-a276-2875fa4f11d4/disk.config'/>
      <target dev='vdz' bus='virtio'/>
      <alias name='virtio-disk25'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

I'm wondering if OpenStack needs to present the config drive differently so that it's usable by the Windows guest when running under kvm.

I'm running OpenStack/devstack on Ubuntu 12.04.2 LTS. libvirtd --version shows 0.9.8. nova is from github master, the latest commit is this one:

commit 0ca55dcccdd76181a3b9311945e0b99ae6381e53
Merge: 9dac4e6 7f1b1b6
Author: Jenkins <email address hidden>
Date: Fri Mar 15 22:18:26 2013 +0000

    Merge "Revert 1154253 causes XenServer image compat issue"

Tags: libvirt
Revision history for this message
Chuck Short (zulcss) wrote :

Which version of libvirt, which os and which version of openstack?

Changed in nova:
status: New → Incomplete
Revision history for this message
Brant Knudson (blk-u) wrote :

I'm running OpenStack/devstack on Ubuntu 12.04.2 LTS. libvirtd --version shows 0.9.8. nova is from github master, the latest commit is this one:

commit 0ca55dcccdd76181a3b9311945e0b99ae6381e53
Merge: 9dac4e6 7f1b1b6
Author: Jenkins <email address hidden>
Date: Fri Mar 15 22:18:26 2013 +0000

    Merge "Revert 1154253 causes XenServer image compat issue"

description: updated
Brant Knudson (blk-u)
Changed in nova:
status: Incomplete → New
Revision history for this message
Chuck Short (zulcss) wrote :

Please attach your nova.conf.

Changed in nova:
status: New → Incomplete
Revision history for this message
Brant Knudson (blk-u) wrote :

I ran this a couple of times, once with the default config_drive_format, and once with config_drive_format = vfat. Other than adding config_drive_format = vfat, I didn't make any change to the nova.conf file and used the result of devstack/stack.sh. Attached is the nova.conf used after I added config_drive_format = vfat.

Changed in nova:
status: Incomplete → New
tags: added: libvirt
Revision history for this message
Chris Behrens (cbehrens) wrote :

When presenting new disks to windows images (like in the vfat) case, I believe it is normal to have to go to Disk Management and manually assign a drive letter. :-/

In the ISO case, it really should be presented as a cdrom device.. if we're presenting it as a disk, that certainly seems like a bug.

Revision history for this message
Michael Still (mikal) wrote :

Someone with test windows guests needs to duplicate this problem and then see if presenting the disk as a cdrom fixes the problem.

Changed in nova:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Jim Lindeman (lindj-f) wrote :

The issue is that Windows doesn't like to see a disk block-device formatted with ISO-9660 but if that same config-drive was presented as a cdrom block-device, then Windows mounts it with a drive letter fine and dandy.

It's not clear to me in Nova why a config-drive is not always presented as a cdrom block-device instead of a disk block-device. I'm guessing the reason it was presented as a disk drive was to allow the Linux guest to clear any sensitive data after the initial boot & consumption of config-drive data.

But in a hack I've made to the nova-driver to support using IDE instead of virtio (triggered by a "disk-bus-type" = "ide" property in glance), I changed that code to also present the config-drive as a cdrom on 'hdb'. Ideally, it would be nice if OpenStack could just "know" if the underlying image was Windows and then choose to present the config-drive as cdrom block-device, but that would require introspection of the image or require another glance-property to be set by the user.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/36891

Changed in nova:
assignee: nobody → Tony Yang (tonyyang132)
status: Confirmed → In Progress
Matt Riedemann (mriedem)
tags: added: folsom-backport-potential grizzly-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/36891
Committed: http://github.com/openstack/nova/commit/7f4b5771633f519a54aae985ae526418114b1a29
Submitter: Jenkins
Branch: master

commit 7f4b5771633f519a54aae985ae526418114b1a29
Author: Tony Yang <email address hidden>
Date: Thu Jul 18 18:45:24 2013 +0800

    Config drive attached as cdrom

    Some guest OSes (e.g. Windows) require config drive to be a cdrom device
    to access the iso9660 filesystem on it. Option config_drive_format is
    therefore set to also control the device type of config drive. If it's
    set to 'iso9660', config drive will be cdrom; if it's 'vfat', config
    drive will be disk.

    DocImpact
    Fixes: bug #1155842
    Change-Id: I6c08b1b8040a1fd0db8e2b3b1fc798060733001f

Changed in nova:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/grizzly)

Fix proposed to branch: stable/grizzly
Review: https://review.openstack.org/39511

Matt Riedemann (mriedem)
tags: removed: grizzly-backport-potential
Revision history for this message
Alan Pevec (apevec) wrote :

Folsom is now open for security fixes only.

tags: removed: folsom-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/grizzly)

Reviewed: https://review.openstack.org/39511
Committed: http://github.com/openstack/nova/commit/2af0a078851a39ebad2cd1969ec3d52c49c15159
Submitter: Jenkins
Branch: stable/grizzly

commit 2af0a078851a39ebad2cd1969ec3d52c49c15159
Author: Tony Yang <email address hidden>
Date: Thu Jul 18 18:45:24 2013 +0800

    Config drive attached as cdrom

    Some guest OSes (e.g. Windows) require config drive to be a cdrom device
    to access the iso9660 filesystem on it. Option config_drive_format is
    therefore set to also control the device type of config drive. If it's
    set to 'iso9660', config drive will be cdrom; if it's 'vfat', config
    drive will be disk.

    DocImpact
    Fixes: bug #1155842
    Change-Id: I6c08b1b8040a1fd0db8e2b3b1fc798060733001f
    (cherry picked from commit 7f4b5771633f519a54aae985ae526418114b1a29)

Revision history for this message
Alan Pevec (apevec) wrote :

This causes a regression https://bugzilla.redhat.com/show_bug.cgi?id=997649

config_drive_format parameter default value is iso9660 but it wasn't actually used until this fix so effective default with libvirt was disk, which will break existing installs without this parameter explicitly set.

Thierry Carrez (ttx)
Changed in nova:
milestone: none → havana-3
status: Fix Committed → Fix Released
Revision history for this message
Tony Yang (tonyyang132) wrote : AUTO: Fan Y Yang is on vacation (returning 09/09/2013)

I am out of the office until 09/09/2013.

Zhao Fang ZF Han/China/IBM will back me up for OSEE build and multitenancy
dev issues. For other questions please contact my manager Yi Ping
Gong/China/IBM. Thanks.

Note: This is an automated response to your message "[Bug 1155842] Re:
config drive not visible to windows" sent on 09/05/2013 23:40:45.

This is the only notification you will receive while this person is away.

Thierry Carrez (ttx)
Changed in nova:
milestone: havana-3 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.