Bug 189097 - [hyper-v] [patch] 10-STABLE breaks Windows Azure compatibility [regression]
Summary: [hyper-v] [patch] 10-STABLE breaks Windows Azure compatibility [regression]
Status: Closed Feedback Timeout
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Mark Linimon
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2014-04-29 07:00 UTC by Barry Boone
Modified: 2016-09-16 16:00 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Boone 2014-04-29 07:00:00 UTC 
I've been testing FreeBSD 10 on the Windows Azure cloud platform, which
is naturally very similar to a Hyper-V environment.

FreeBSD 10.0-Release, and 10.0p1 both work fine under Azure.  I've been
able to get a modified version of the WALinuxAgent script working, and
can provision the OS from the Azure interface and all seems stable and good.

During testing, I created an image with the 10-STABLE kernel.  An MFC to
the stable branch, I believe revision r263065, changed the way that the
driver scans for virtual IDE/SCSI devices.  The effect, is that while the
main OS disk is found and mounted, the Microsoft "temporary" disk that is
allocated for use as temp space and/or swap, does not get detected on bootup.

Example:

Under 10.0-RELEASE...

da0 at blkvsc0 bus 0 scbus1 target 0 lun 0
da0: <Msft Virtual Disk 1.0> Fixed Direct Access SCSI-4 device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 30720MB (62914560 512 byte sectors: 255H 63S/T 3916C)
da1 at blkvsc1 bus 0 scbus2 target 1 lun 0
da1: <Msft Virtual Disk 1.0> Fixed Direct Access SCSI-4 device
da1: 300.000MB/s transfers
da1: Command Queueing enabled
da1: 61440MB (125829120 512 byte sectors: 255H 63S/T 7832C)

Under 10-STABLE, da1 (blkvsc1) is not detected at all.

Fix: 

In the file sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c

change the STORVSC_MAX_TARGETS value to 2.

i.e. 

#define STORVSC_MAX_TARGETS (2)

This fixed the issue for me, with this one line patch, I have 10-STABLE
working perfectly on Azure again.
How-To-Repeat: Compile 10-STABLE's generic kernel, make installkernel.  To get back to
normal, boot the 10.0p1 release kernel.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-05-04 03:42:58 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-emulation

Over to maintainer(s).
Comment 2 Glen Barber freebsd_committer freebsd_triage 2014-05-04 03:58:29 UTC 
Responsible Changed
From-To: freebsd-emulation->gjb

I'm fighting with similar problems. 

In addition, can you send me your WALinuxAgent changes?  I'm 
fighting other issues there, which you may have fixed already.
Comment 3 Glen Barber freebsd_committer freebsd_triage 2014-06-20 10:43:06 UTC 
Return to pool.
Comment 4 Dexuan Cui 2015-12-09 10:07:04 UTC 
This should be a duplicate of bug 194376, which was fixed.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2016-05-20 07:43:11 UTC 
To submitter: did the fix from 194376 fix this problem?
Comment 6 Mark Linimon freebsd_committer freebsd_triage 2016-09-16 16:00:21 UTC 
Feedback timout (> 3 months).