[Differential] [Updated] D5473: ATA/ATAPI6 device emulation in bhyve
mav added a comment. It was definitely significant amount of work, but I am not sure what motivation was behind it. Why do we need it after already having much more featured AHCI-based ATA/ATAPI emulation? Are there any significant OS not supporting AHCI? There is significant amount of code duplication between implementations, plus this one obviously requires more work to be complete. REVISION DETAIL https://reviews.freebsd.org/D5473 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: iateaca, grehan, neel, tychon, mav Cc: freebsd-virtualization-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Commented On] D5473: ATA/ATAPI6 device emulation in bhyve
mav added a comment. In https://reviews.freebsd.org/D5473#117346, @iateaca wrote: > The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers. > What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too. I personally see quite little sense in supporting so old legacy guests. I agree that there can be "some cases", but I am not sure they worth the time spent and code size growth. Other then legacy guests support this code does not give us anything useful -- legacy ATA will be by definition much slower and less functional then its AHCI counterpart. It will require dozens of emulated register accesses per I/O, comparing to only several for AHCI, and won't support command queuing. Though obviously nice and clean unified implementation would look better. In your patch you are one more time reimplementing some subsets of ATA and ATAPI commands handling, already done much wider for AHCI. It would be much better to have single device emulation code, interfacing with different controller code parts. But it would also take much more time (you are rigth that it would require existing code redesign), for the same little reason, so I am not sure how good is that idea. It needs investigation. REVISION DETAIL https://reviews.freebsd.org/D5473 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: iateaca, grehan, neel, tychon, mav Cc: freebsd-virtualization-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Commented On] D5473: ATA/ATAPI6 device emulation in bhyve
iateaca added a comment. In https://reviews.freebsd.org/D5473#117324, @mav wrote: > It was definitely significant amount of work, but I am not sure what motivation was behind it. Why do we need it after already having much more featured AHCI-based ATA/ATAPI emulation? Are there any significant OS not supporting AHCI? There is significant amount of code duplication between implementations, plus this one obviously requires more work to be complete. The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers. What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too. REVISION DETAIL https://reviews.freebsd.org/D5473 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: iateaca, grehan, neel, tychon, mav Cc: freebsd-virtualization-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Commented On] D5473: ATA/ATAPI6 device emulation in bhyve
iateaca added a comment. In https://reviews.freebsd.org/D5473#117352, @mav wrote: > In https://reviews.freebsd.org/D5473#117346, @iateaca wrote: > > > The motivation is to run older versions of operating systems such as FreeBSD 4 which does not have AHCI drivers. > > What do you mean by code duplication ? I think only the ATAPI CDROM logic could be common but the current implementation from AHCI can not be used with the ATA data strcutures. If we want to achive this, I think a redesign of AHCI ATAPI is required too. > > > I personally see quite little sense in supporting so old legacy guests. I agree that there can be "some cases", but I am not sure they worth the time spent and code size growth. Other then legacy guests support this code does not give us anything useful -- legacy ATA will be by definition much slower and less functional then its AHCI counterpart. It will require dozens of emulated register accesses per I/O, comparing to only several for AHCI, and won't support command queuing. > > Though obviously nice and clean unified implementation would look better. In your patch you are one more time reimplementing some subsets of ATA and ATAPI commands handling, already done much wider for AHCI. It would be much better to have single device emulation code, interfacing with different controller code parts. But it would also take much more time (you are rigth that it would require existing code redesign), for the same little reason, so I am not sure how good is that idea. It needs investigation. Totally agree with you, there are no many reasons to use ATA instead of AHCI when you have support for it. Though I think there is a good reason having the ATA/ATAPI emulation in bhyve since Peter came with this idea. REVISION DETAIL https://reviews.freebsd.org/D5473 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: iateaca, grehan, neel, tychon, mav Cc: freebsd-virtualization-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
bhyve and CARP?
I am considering setting up a bhyve virtual machine to run pfSense. Not too thrilled with the CPU heat on the PC Engines APU1D4 when under heavy load, but don't want to rely entirely on a VM. As I like still having internet if I would have to take my server offline for disk replacement or other issues, having web access to search for errors is a big plus. So in order to avoid spending money on a new piece of hardware I thought why not do a VM with CARP fail over to the physical. I am not finding much searching on FreeBSD byhve and CARP, I know its somewhat of an issue withing VMware on ESX making sure you enable the right options on the virtual switches and interfaces. Enable promiscuous mode on the vSwitch Enable "MAC Address changes" Enable "Forged transmits" Before I got started on the setup I was curious if anyone has done something similar, or know if this isn't possible on bhyve at the current version? I am running my system currently on 10.3-BETA3. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
[Differential] [Updated] D5473: ATA/ATAPI6 device emulation in bhyve
grehan added a comment. Support for legacy o/s's has driven much of bhyve development. I'm all for this, though I agree there should be some consolidation of code that could be shared between ATA/ATAPI and AHCI. REVISION DETAIL https://reviews.freebsd.org/D5473 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: iateaca, neel, tychon, mav, grehan Cc: freebsd-virtualization-list ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve and CARP?
On 1/03/2016 8:43 AM, dweimer wrote: I am considering setting up a bhyve virtual machine to run pfSense. Not too thrilled with the CPU heat on the PC Engines APU1D4 when under heavy load, but don't want to rely entirely on a VM. As I like still having internet if I would have to take my server offline for disk replacement or other issues, having web access to search for errors is a big plus. So in order to avoid spending money on a new piece of hardware I thought why not do a VM with CARP fail over to the physical. I am not finding much searching on FreeBSD byhve and CARP, I know its somewhat of an issue withing VMware on ESX making sure you enable the right options on the virtual switches and interfaces. Enable promiscuous mode on the vSwitch Enable "MAC Address changes" Enable "Forged transmits" Before I got started on the setup I was curious if anyone has done something similar, or know if this isn't possible on bhyve at the current version? I am running my system currently on 10.3-BETA3. this makes one wonder if it would be possible to run the pfsense code in a vnet Jail. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve and CARP?
On 03/01/16 22:36, Julian Elischer wrote: this makes one wonder if it would be possible to run the pfsense code in a vnet Jail. That would be really cool and handy. The pfsense kernel is unfortunately just a bit modified. I haven't tried but I think many things will fail. ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve and CARP?
Hi, On 03/01/16 18:43, dweimer wrote: I am considering setting up a bhyve virtual machine to run pfSense. Not too thrilled with the CPU heat on the PC Engines APU1D4 when under heavy load, but don't want to rely entirely on a VM. As I like still having internet if I would have to take my server offline for disk replacement or other issues, having web access to search for errors is a big plus. So in order to avoid spending money on a new piece of hardware I thought why not do a VM with CARP fail over to the physical. I am not finding much searching on FreeBSD byhve and CARP, I know its somewhat of an issue withing VMware on ESX making sure you enable the right options on the virtual switches and interfaces. Enable promiscuous mode on the vSwitch Enable "MAC Address changes" Enable "Forged transmits" Before I got started on the setup I was curious if anyone has done something similar, or know if this isn't possible on bhyve at the current version? I am running my system currently on 10.3-BETA3. I am running two postgres VMs with DRBD and not CARP but UCARP which should be 100% compatible with CARP. Each VM has a tap interface and each tap is bridged to a bridge interface. There is no need for special configuration. Everything works as expected. HTH, Nikos ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
Re: bhyve and CARP?
On 2016-03-01 3:01 pm, Nikos Vassiliadis wrote: On 03/01/16 22:36, Julian Elischer wrote: this makes one wonder if it would be possible to run the pfsense code in a vnet Jail. That would be really cool and handy. The pfsense kernel is unfortunately just a bit modified. I haven't tried but I think many things will fail. I have seen threads on the pfSense forums about people trying to do this, as far as I know, they have all failed. I have pfSense installed so far, but waiting till later to swap my NIC in the server with a quad port NIC before setting up all the interfaces and beginning the CARP configuration. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
