Hyper-V and FreeBSD

joel@ said:
Everything should be in GENERIC in ALPHA4/ALPHA5.

That is not a useful answer. I did svn update /usr/src about 20 hours ago, so that would be alpha4 as far as I can tell. There is a device entry for hyperv, but it doesn't appear to be effective. The GENERIC build from that will only boot with fast IDE manually disabled, and will not shut down without manual intervention using PS. If people are running it "with no problems at all", it would be nice to know how they did that. If they are really still doing manual intervention on boot and shutdown, that is NOT "no problems". I do see the hn0 device is created, but hadn't looked before and don't really care because network speed is not an issue if the VM won't reboot automatically with the host. On top of that, de0 still requires bouncing after boot, so that doesn't appear to be fixed in the driver set. There was a comment from @grehan three months ago about creating a wiki entry, but that still does not exist. My point was that there is a lot of information out there that doesn't apply to base/head today, and absolutely nothing that does. Even this thread which claims to be the place to get current info does nothing more than make unsubstantiated claims that it is working.
 
Last edited by a moderator:
joel@ said:
I guess you've already tried asking on current@freebsd.org ?

Why would I? This is a hyper-v specific issue as far as I can tell, and this thread is targeted to address that space. I don't see what is so difficult about backing up the claim that 'it works' with a simple list of the steps that it took to make that happen.

I just did a fresh svn update & and build after my last note. dmesg shows alpha5, and shutdown -r now still requires manual intervention with a PS script. I will buy an argument that the manual boot problem is something to take to current since that is glabel missing existing labels that are picked up when fast ide is turned off, but shutdown has to be an integration issue, and it clearly doesn't work. Claims on this thread say there are no problems, so again: what steps were required to get there?
 
So I interpret the silence as an indication that nobody actually has 10-alpha? running "without problems". Even those who really meant that they have the synthetic NIC running could have indicated that they turned off the legacy NIC, or commented it out in rc.conf for those that are booting back to 9.x. You can't leave de0 configured at the same time you claim there are no problems! With de0 configured, there is no IPv4 path out of the box until de0 is bounced. The IPv6 path works without effort on the synthetic NIC, but in any case that NIC is a performance optimization, not a fundamental for getting FreeBSD running on HYPERV in a production context.

How does one go about building/loading the necessary modules to have a shutdown/reboot happen without manual intervention on the host? After that works, how does one get the necessary support built for the host to signal a shutdown/reboot to the FreeBSD guest?

Without those, the fastest NIC in the world is pointless, because the whole thing is just a toy.
 
tonyhain said:
So I interpret the silence as an indication that nobody actually has 10-alpha? running "without problems". Even those who really meant that they have the synthetic nic running could have indicated that they turned off the legacy nic, or commented it out in rc.conf for those that are booting back to 9.x. You can't leave de0 configured at the same time you claim there are no problems! With de0 configured, there is no IPv4 path out of the box until de0 is bounced. The IPv6 path works without effort on the synthetic nic, but in any case that nic is a performance optimization, not a fundamental for getting FreeBSD running on HYPERV in a production context.

How does one go about building/loading the necessary modules to have a shutdown/reboot happen without manual intervention on the host? After that works, how does one get the necessary support built for the host to signal a shutdown/reboot to the FreeBSD guest?

Without those, the fastest nic in the world is pointless, because the whole thing is just a toy.

I simply downloaded the 10.0-ALPHA2 ISO and installed it on a newly created VM. After that I added the following to /boot/loader.conf and added network configuration for hn0 to /etc/rc.conf before rebooting.

Code:
hv_storvsc_load=YES
hv_netvsc_load=YES
hv_vmbus_load=YES
hv_utils_load=YES
hv_ata_pci_disengage=YES
 
  • Thanks
Reactions: vvm
ph0enix said:
I simply downloaded the 10.0-ALPHA2 ISO and installed it on a newly created VM. After that I added the following to /boot/loader.conf and added network configuration for hn0 to /etc/rc.conf before rebooting.

Code:
hv_storvsc_load=YES
hv_netvsc_load=YES
hv_vmbus_load=YES
hv_utils_load=YES
hv_ata_pci_disengage=YES

Thanks for the constructive reply. The loader.conf set had not shown up in anything I had come across before. I had originally assumed I would have to build from src source to get hyperv turned on, so I had started with a fresh 9.2 w/o without src/ports/games, then pulled in base/head for a completely fresh clean start. That approach still fails to shutdown without manual intervention on the host, or boot without the magic string.

This morning I pulled down FreeBSD-10.0-ALPHA5-amd64-memstick.img and converted that to vhd (because I found a comment about someone else doing that before I saw your reply). The system installed from that will shutdown/reboot without manual intervention on the host (and did so before adding to loader.conf), but will not load the disk on boot, even after adding your instructions about loader.conf. Clearly there is something in the distributed builds that the instructions at .../handbook/makeworld.html didn't pick up. To be investigated...

I added a label in the partition editor during install, but those ended up in /dev/gpt rather than /dev/label. Pointing fstab at /dev/gpt didn't help. Adding another label with [FILE}glabel[/FILE] and pointing fstab at that makes no difference. Booting to /dev/label w/ with your instructions for loader.conf results in:
Code:
http://tndh.net/~tony/hyper-v_disk_fail.jpg
Whichever label is uncommented in fstab will load whenever
Code:
set hw.ata.disk_enable=1
is manually inserted to the bootloader sequence, but storvsc panics without that flag. I wouldn't be surprised if there is another step I haven't found yet, but that was the point in my asking here. I guess one way would be to add
Code:
hw.ata.disk_enable=1
to loader.conf, but that seems like a bad-idea hack, particularly if other people have it running without that.
Code:
#glabel status
gptid/69b8...220  N/A  ada0p1
label/rootfs          N/A  ada0p2
label/swap           N/A  ada0p3
#mount
/dev/label/rootfs on / (ufs, local, journled soft-updates)
devfs on /dev (devfs, local, multilabel)
One thought::: how much memory are you running with? Is it possible I am not giving it enough for the fastide module?
 
Installing from the ISO over an existing VM showed that the problem with shutdown was the legacy NIC, not the source vs. distribution I was suspecting in the last post. The new VM built earlier today never had the legacy NIC and would shutdown/reboot fine, while the one built over the top of a 9.0 system still had it in the VM settings so it would not shutdown without manual intervention. Removing that from the VM settings allowed that VM to shutdown/reboot correctly, then adding it back (even defined down) would prevent a complete shutdown. This was also the case on the 9.2 system where I had left it defined to boot back for additional build attempts.

The /boot/loader.conf entries from @ph0enix appear to be redundant because dmesg complains about
Code:
hv_vmbus_load=YES
already being loaded. In fact for the three VM's (distribution alpha-5 IMG and ISO, as well as a fresh build this afternoon of base/head), removing all of those entries still allows everything to work as far as I can tell, given that there an entry for
Code:
hw.ata.disk_enable=1
to work around the storvsc boot time panic.

If someone has an alpha-n system that doesn't require disabling fastide support, it would be nice to know what you did. For the 3 VM's I have here, creating gpt or generic labels are not sufficient. The systems will find and mount those labels, but only after fastide is turned off.
 
Last edited by a moderator:
tonyhain said:
. . .
If someone has an alpha-n system that doesn't require disabling fastide support, it would be nice to know what you did. For the 3 VM's I have here, creating gpt or generic labels are not sufficient. The systems will find and mount those labels, but only after fastide is turned off.

What _exatcly_ You do?

I do this:

No/zero Legacy LANCard ( de0) _both_ on install and "after install" step
Only Syntetic LANCard

==
Convert to .VHD FreeBSD-10.0-ALPHA4-amd64-memstick.img
Attach as disk to secondary ATA channel, boot and install:
-- syntetic LANCard work ( may be need run "dhclient hn0" )
==

Shutdown from Hyper-V GUI -- work
Reboot ( by type word reboot in *BSD shell command line ) -- work ( with some "KDB: stack backtrace" )

( I already send info about this ( and about "[font=Arial]exclusive sleep mutex NetVSCLock (network driver)[/font]" ) to MS
----- Original Message -----
From: "V. . . M. . ." <vvm(at)ZZZZZZZZZZZZZZZZ
To: "KY Srinivasan" ; "Abhishek Gupta (LIS)" ; . . .
Cc:
Sent: Monday, October 07, 2013 6:31 PM
Subject: Is already fixed in 10.0-ALPHA5? Or no? Fw: 1) FreeBSD-10.0-ALPHA4-amd64-memstick.img -- Error on step init
syntetic LANCard ( device hn0 ) exclusive sleep mutex NetVSCLock (network driver) 2) Error on Shutdown

. . .
--
)
 
I just upgraded to 10.0-ALPHA5 and the system wouldn't boot because it couldn't find the root fs on /dev/ada0p2. I told it to boot from /dev/da0p2 instead and it came up fine so I modified /etc/fstab accordingly and it boots on its own now.
Also, the GENERIC kernel has hyper-v support in it now so there is no need for the entries in loader.conf.

My VM is configured with 1GB of RAM.
 
  • Thanks
Reactions: vvm
ph0enix said:
I just upgraded to 10.0-ALPHA5 and the system wouldn't boot because it couldn't find the root fs on /dev/ada0p2. I told it to boot from /dev/da0p2 instead and it came up fine so I modified /etc/fstab accordingly and it boots on its own now.
Also, the GENERIC kernel has hyper-v support in it now so there is no need for the entries in loader.conf.

My VM is configured with 1GB of RAM.

So I still can't figure out how you got there. Did you "upgrade" alpha-2 or did you "reinstall" over the top? I tried simply editing fstab and leaving out set hw.ata.disk_enable=1. Boot stopped with panic. I increased memory from 768M to 1G. Still panics. I reinstalled from FreeBSD-10.0-ALPHA5-amd64-disc1.iso (had to disable fastide just to get that started). Still panics. I reinstalled from FreeBSD-10.0-ALPHA5-amd64-memstick.img(vhd) (had to disable fastide just to get that started). (I do realize those should be identical, but just to cover all options...) Still panics. The only thing I did not do today was generate an entirely new VM, because I had done that yesterday and that one has the same behavior. I even rebuilt the third one from base/head to pick up today's Outstanding Workchange item for hyperv. Still panics.

To a first order this sounds like a bug in the integration service, because if I disable fastide I get to error 19 when fstab is pointing to the wrong device, but with fastide enabled it panics before it gets there. To me it should drop to error 19 if fstab is pointing to /dev/ada0 rather than /dev/da0. Clearly it is giving up for lack of a disk on the vmbus, so it is not clear why your system would present /dev/da0 with fastide on, while mine does not appear to present any disk unless I turn fastide off. The only thing I can think of is there might be a compatibility bug in the integration service based on which server version you are running. Mine is running on SBS2008-sp2(server2008). I would guess the development is done on something newer, and would not be surprised to find out that it was not tested on this rather old and obscure version of the server. One would hope that windows-update would keep hyper-v current, but maybe it is not. If this is a known issue, it would be useful to have it documented where search engines can find it. I can live with turning off fastide until I can migrate the VM's to the SBS2011(server2008-r2) system, but if fastide is supposed to work on the older server version, I would like to understand why I can't get the configuration right.
 
Win 2012 R2 / 2008 R2 0) set RAM to 1512Mb 1) Not use set hw.ata.disk_enable=1

tonyhain said:
might be a compatibility bug in the integration service based on which server version you are running. Mine is running on SBS2008-sp2(server2008).

Windows Server 2008 "R0" -- is total outdated

tonyhain said:
until I can migrate the VM's to the SBS2011(server2008-r2) system,

Yes, SBS2011 -- is pretty good choice

Use as Hyper-V Server
-- Windows Server 2012 R2 ( or use Windows Server 2012 "R0" until release SC VMM 2012 R2 )
or
-- Windows Server 2008 R2 with Service Pack 1
( and run SBS as 1-3 virtual comps )

P.S.
as Fw:
tonyhain said:
I tried simply editing fstab and leaving out set hw.ata.disk_enable=1. Boot stopped with panic. I increased memory from 768M to 1G. Still panics. I reinstalled from FreeBSD-10.0-ALPHA5-amd64-disc1.iso (had to disable fastide just to get that started). Still panics. I reinstalled from FreeBSD-10.0-ALPHA5-amd64-memstick.img(vhd) (had to disable fastide just to get that started). (I do realize those should be identical, but just to cover all options...) Still panics.

(
Please read my message in Private Messages
)

Try this ( it is my configuration) :

0) set RAM to 1512Mb ( as minimum on install step) , set as "Static" i.e. not Dynamic Memory

1) Not use set hw.ata.disk_enable=1

1b) As I already write:
==
No/zero Legacy LANCard ( de0) _both_ on install and "after install" step
Only Syntetic LANCard
==

2)
install from FreeBSD-10.0-ALPHA5-amd64-memstick.img(vhd) with _enabled_ fastide
it "get started" as need/"very well"
 
vvm said:
Windows Server 2008 "R0" -- is total outdated

That may be true, but there is no definitive statement one way or the other about if it should work. All the public discussion is about hyper-v with the implication that all versions work. If that is not true, someone needs to state that.

vvm said:
Yes, SBS2011 -- is pretty good choice

Use as Hyper-V Server
-- Windows Server 2012 R2 ( or use Windows Server 2012 "R0" until release SC VMM 2012 R2 )
or
-- Windows Server 2008 R2 with Service Pack 1
( and run SBS as 1-3 virtual comps )

Is that a requirement from Microsoft for the integration services to work, or just your personal preference? It would be useful to get this resolved before 10 goes to RELEASE, so documentation can make note of any limitations or configuration requirements.

0) set RAM to 1512Mb ( as minimum on install step) , set as "Static" i.e. not Dynamic Memory

That is not a requirement, as I have installed and have 3 running VM's using half that much memory, and Ph0enix also uses less. Just to prove the point, I increased one of my VM's to 1536MB and it still panic's.


1) Not use set hw.ata.disk_enable=1

1b) As I already write:
==
No/zero Legacy LANCard ( de0) _both_ on install and "after install" step
Only Syntetic LANCard
==

The legacy nic can be installed before, it just needs to be removed to allow shutdown. I have 2 VM's where that was the case, one as an overwrite of a 9.0, and one as a 9.2 used to build fresh from base/head.

It is useful to publish recipe's and configuration steps for things that are known to work (actually much more useful than unsubstantiated claims that 'it works' as in the early part of this thread). It is not useful to claim there are minimum requirements, or steps to be avoided when those are personal preferences rather than real requirements. People are using search engines to find out how to make FreeBSD work on hyper-v, and false claims about minimum requirements will make their life more difficult.

If anyone knows how to get a resolution about fastidesupport in hyperv-(pre r2), please let me know, or forward a pointer to this thread to someone that can make a clear statement. My primary interest here is public documentation about minimum requirements and configurations. If it turns out that this really is just a bug and it is supposed to work for all versions of hyper-v, fixing the pre-r2 integration would be even better.
 
tonyhain said:
All the My primary interest here is public documentation about minimum requirements and configurations.
( Number 2: @tonyhain please, please, please read Private Messages (see on top of this page) )


1)

Ask any of this people:
----- Original Message ----- From: <vvm@ZZZZZZZZZZZZZZZ>
To: "Abhishek Gupta (LIS)"; <freebsd-virtualization@freebsd.org>
Cc: "Alexander Motin" ; "KY Srinivasan" ; "Larry Melia"
Sent: Tuesday, October 01, 2013 10:34 AM
Subject: Again: Tmp. disable BlkVSC (paravirtual IDE) functional? On ATA Channel N2 -- minimum Re: Disabling ATA driver for IDE devices on Hyper-V Re: ATA controller and Hyper-V "synthetic storage driver" handle the IDE disks devices ( but not for the CD-ROM)



> Hi!
>
>> This may have been asked before but the solution we have currently is less than ideal. Please bear with me on the
>> repetition and provide any suggestions you may have.
>>
>> One of the issues with Hyper-V is that it does not virtualize the CD device and therefore we rely on the ATA driver in
>> the guest operating system to manage CDROMs.
>> What we would like to do is disable the ATA driver for all device types except the CDROM in the presence of Hyper-V.
>
 
Last edited by a moderator:
Good news: _Both_ FastIDE and CD-Rom work in FreeBSD 10 on Hyper-V

Good news:

Both FastIDE and CD-Rom work in FreeBSD 10 on Hyper-V

Microsoft hyperv dev team:

One of the issues with Hyper-V is that it does not virtualize the CD device and therefore
we rely on the ATA driver in the guest operating system to manage CDROMs.
What we would like to do is disable the ATA driver for all device types except the CDROM in the presence of Hyper-V.



vvm :

>> Disable both primary and secondary ATA controller prevent use CD-ROM
>> device in VM ( guest)
>>
>> Because "synthetic storage driver" not handle CD-ROM devices
>> ( IMHO, even more: Hyper-V host work with CD-ROM only as "PCI bus" device)

mav@ :

A.M.> Then may be possibility of blocking/hiding specific ATA channels or
A.M.> devices could be investigated.


mav@ :
>> Unfortunately, CAM subsystem used for both ATA and SCSI stacks in
>> FreeBSD 9.x and above is mostly unaware of "NewBus" infrastructure
>> used for driver probe and attachment. That is why you can't replace
>> driver for a single disk in the same way as you replaced driver for
>> the whole controller. The highest level present in "NewBus" is ATA
>> channel. So if disk and CD-ROM are always live on different channels,
>> you can create dummy driver not for the whole controller (atapciX),
>> but for single hardcoded ATA channel (ataX).



Microsoft hyperv dev team:

>
> We have decided to have the DVD and the root device on different channels
> as that appears to be the simplest way to address this problem.
. . .
> . . . dummy driver for a single hardcoded ATA channel.
>The boot device has to be on the first channel,
> this would require the ISO device to be on the second channel.
>



mav@ :
==
Revision 256304 (view) . . .- [select for diffs]
Modified Thu Oct 10 22:46:49 2013 UTC
File length: 5783 byte(s)


Allow the legacy CDROM device to be accessed in a FreeBSD guest,
while still using enlightened drivers for other block devices.

Submitted by: Microsoft hyperv dev team, mav@ Approved by: re@
==

From: vvm
To: mav@
==
Thanks for patch!
==

Microsoft hyperv dev team:
==
Thanks Alexander.
==


Microsoft hyperv dev team:
==
We tested the patch and it seems to work fine.
We observed that the CDROM is not accessible on channel 0 but is accessible on channel 1 as intended.
The solution is good enough as the Hyper-V UI in general biases a user
to attach the root device to channel 0
and the CDROM to channel 1
and we can further reinforce this for FreeBSD users.
I think this solution is good enough for now and we can explore more later.
==

vvm:
==
Yes: "this solution" (
"the root device to channel 0" with syntectic ATA driver ,
"CDROM accessible on channel 1" with non-Hyper-V specific ATA driver
) "is good enough for now"

I.e.:
1) "this solution" "will let the ATA driver install FreeBSD"
2) and is "way to enable FastIDE"

==


Microsoft hyperv dev team:
==
Many many thanks for getting this to work.
==
 
vvm said:
( Number 2: @tonyhain please, please, please read Private Messages (see on top of this page) )

1) I have pop-ups turned off, so I never see any messages due to the way this forum is managed. Whenever I click on the private message link it tries to pop a new window, so I get an informational pop-up that it is blocked. Yes I could turn that on, but see 2)

2) I want this discussion available to others that are using public search engines. It has been really frustrating to find anything current about hyper-v configurations, and using private messages doesn't fix that for others that are in the same situation.

Ask any of this people:

Thank you. I sent a note to freebsd-virtualization@freebsd.org
If I get an off-list reply I will provide a summary here so others know what to expect.
 
Last edited by a moderator:
Off-list response for note sent to freebsd-virtualization@freebsd.org
> You are correct. As of now we have only tested the drivers on Server 2012.
> You can get them to work on Server 2008R2 but Server 2008 will have
> some problems. Currently we are focused on getting the drivers
> functional on Server 2012 for FreeBSD 10 and then we may start
> expanding to past versions of Windows servers if there is sufficient demand.
>
> I will have one of our devs try to repro the problem and understand if it is a
> hidden bug on WS 2012 as well.

I can live with fastide turned off until I get to a place where I can put these on the SBS2011 system. I can't make a business case for fixing it for my use, but I will ask around and see if I can find anyone else still running SBS2008 that would have one. I suspect that if it didn't get fixed, but was documented as a caveat in the release notes, most people would be ok with it. After all, if they have been doing it prior to 10, they were doing it without fastide, and suffering through the inability to shutdown with the legacy nic on top of it.

If anyone can make a business case for fixing the older version of hyper-v, I would suggest sending it to that mailbox.
 
What is the trick to getting DHCP to work? Right now, for whatever reason, I need to type dhclient hn0 right after logging in?
 
skocdopolet said:
Lopezi, it should be ifconfig_hn0="SYNCDHCP media 100baseTX mediaopt full-duplex"

Thanks, that appears to work sometimes. There are times when it is booting that it'll sit and wait indefinitely. I have to turn off the virtual machine and try again and it boots all the way through.

Outside of that, the virtual machine boots fine and appears to function ok. I did have errors trying to compile various ports (too many to list here). I'm assuming that this may be related to things being in flux?

Outside of the mailing list,s is there every going to be a forum section directly geared for Hyper-V? Just curious.
 
lopezi said:
Outside of the mailing lists is there every going to be a forum section directly geared for Hyper-V? Just curious.

Extremely unlikely; traffic is ~zero.
 
Now that those little driver bugs have been fixed -- has anyone tried spinning up a FreeBSD 10 VM on Azure yet?
 
running 11-CURRENT on Hyper-V, working fine

After trying 10-ALPHA and 10-BETA1 and subsequently scanning through the mailing lists I decided to try 11-CURRENT.

I started with snapshot FreeBSD-11.0-CURRENT-amd64-20131015-r256489 and then "upgraded" (compiled the newer kernel) to FreeBSD-11.0-CURRENT-amd64-r257506. With the snapshot build I loaded kde4 and managed to get a working, usable desktop environment. I even managed to get xrdp working so I can use mstsc/RDP to connect into the VM.

Under 11-CURRENT I had to compile everything from ports (I was using it before the announcement of packages being available) and had a few minor snags that I was able to work through. To upgrade the kernel snapshots, I basically followed the instructions as laid out in the FreeBSD Handbook.

So far, so good...I'm not expecting everything to go smoothly as I'm mainly interested in seeing how well everything runs under Hyper-V but so far OK although I haven't really run it through all of its paces. There was a gentlemen on the mailing list that seemed to be exercising VM migration and other features of Hyper-V. I'm looking forward to seeing if he posts his results.
 
Re: running 11-CURRENT on Hyper-V, working fine

lopezi said:
After trying 10-ALPHA and 10-BETA1 and subsequently scanning through the mailing lists I decided to try 11-CURRENT.

I started with snapshot FreeBSD-11.0-CURRENT-amd64-20131015-r256489 and then "upgraded" (compiled the newer kernel) to FreeBSD-11.0-CURRENT-amd64-r257506. With the snapshot build I loaded kde4 and managed to get a working, usable desktop environment. I even managed to get xrdp working so I can use mstsc/RDP to connect into the VM.

Under 11-CURRENT I had to compile everything from ports (I was using it before the announcement of packages being available) and had a few minor snags that I was able to work through. To upgrade the kernel snapshots, I basically followed the instructions as laid out in the FreeBSD Handbook.

I had been running FreeBSD-11.0-CURRENT-amd64-r257506 for quite some time while also updating my ports periodically. I encountered the Java related kernel panic while trying to update any port that looked at Java. I noticed that there was a fix in the newer kernel. Yesterday (Jan. 4, 2014) I pulled down the source (I don't remember exactly which revision). In any event, after compiling and installing the kernel per the handbook directions I had followed previously, I am presented with a kernel panic upon reboot. I decided to pull down the latest VM images for 11.0-CURRENT and try to at least boot with one of them. To no avail. I tried all the VM Images that were in the 11.0-CURRENT branch and each one gave me a kernel panic upon boot. After this I decided to try the FreeBSD-10.0-RC4-amd64-20131231-r260130.vhd VM image that was available. For whatever reason, this one does boot successfully.

Have there been any changes related to Hyper-V code in the 11-CURRENT branch that is way "different" than what is provided in the 10.0-RC4 branch? The pull I did from SVN to upgrade my 11.0-CURRENT kernel should have had whatever "changes" that were available to the 10.0-RC4 release, or is the 11.0-CURRENT really that far off from the 10.0-RC4 branch?
 
Back
Top