bhyve Arch Linux VM emulated with BHYVE : considerations.

Sorry to come back about the "rudeness" you mention a couple of times in the chat ;) However following all messages I would like to highlight a lot of mistakes you've done here and hopefully it might be useful in the future:
  1. Arch Linux VM emulated with BHYVE : considerations --> You should have kept focus in your problems using bhyve (via script vm-bhyve) all the time instead of fanny about mixing subjects.
  2. Don't criticize Bbyve software just because your configuration setup is wrong.
  3. Stop blame developer, or talking about bugs when your configuration is wrong
  4. Passing through graphic card --> it's a different subject not cover for the thread --> Open a new Thread!
  5. Configuration Xorg.conf --> again mixing things --> Open a new Thread!
  6. ssh X11 remote server --> Open a new Thread!
  7. Linux + qemu + kvm --> This is FreeBSD (no Linux) --> Open a new Thread! or go Linux forums
FreeBSD community is probably one the the most helpful, professional and kind , I've ever seen, so please be more straight in the future :)

PD: I would close this post if I were you

You are suggesting me to close this post. Do you want my opinion about what you have told me ? do u think that it would be useful ? I would like to do it because your considerations highlight the fact that for some relevant points you have not read correctly or you haven't understood well what you have read.
 
You are suggesting me to close this post. Do you want my opinion about what you have told me ? do u think that it would be useful ?
You should ask yourself about what you want to achieve with thread.....
Back to square one.
  • Arch Linux VM emulated with BHYVE: good feedback has been provided proving how to install Arch Linux with uefi.
Cheers
 
I do not understand. You made some remarks that had nothing to do with the thread but with me and also that highlight that you didn't understand the reasons why I did that BUT you are telling me that I went off topic and you don't even want me to answer. Your is a nice behavior. It seems that you put into the game with your leg straight and then you want to take off your leg.
 
I do not understand. You made some remarks that had nothing to do with the thread but with me and also that highlight that you didn't understand the reasons why I did that BUT you are telling me that I went off topic and you don't even want me to answer. Your is a nice behavior.
Seriously....
You should ask yourself about what you wanted to achieve with thread.
Are you happy with the feedback provided or not?
 
I'm interested to tell something about these points :
  • Don't criticize Bbyve software just because your configuration setup is wrong.
  • Stop blame developer, or talking about bugs when your configuration is wrong
I have criticized Bhyve because I found some missing features and it's development is slow. The right to be critic belongs to the right of expression. Are you joking ? if expressed with the polite manners can be done. Also my setup wasn't wrong. At the beginning I made a mistake applying the workaround,but then I've fixed it. Bhyve does not support efi variables. It's a feature not yet implemented and some developers talk about it in several sites. I just told the truth. The fact that there is a workaround to unfreeze the installation of linux doesn't change the fact that there is a missing feature. Do you really think that telling the truth means a lack of good manners ? or what ? For you everything is good everytime ? In addition probably u didnt read that my critic hasn't been aggressive and I didn't give up the task. It's not nice to misrepresent the facts,right ?
 
I'm interested to tell something about these points :
  • Don't criticize Bbyve software just because your configuration setup is wrong.
  • Stop blame developer, or talking about bugs when your configuration is wrong
Glad to see finally you focus on the actual topic although only within points 2) and 3) of mi list ;) It looks that you don't say nothing to be added to the rest of the list (4, 5, 6, 7), isn't it?
I would highly recommend you to read FreeBSD Forums Rules thoroughly for avoiding misunderstandings in the future

PD: I liked to see you didn't give up the task :)
 
For the rest of the points I admit that I enjoyed talking about different arguments in the same topic. But because a lot of arguments are tied together and also because I am devoured by curiosity and I want to learn. However this did not stop me from completing the projects. You know that a project can be completed even later and in the while completing some minor and a liittle different tasks can help to reach the main goal ? For me it works like this. Focus shifts slightly from the main goal, but without losing sight of it.
 
To be honest I would not have bothered to install Arch on Bhyve until I read this topic. Working with Alpine, Debian and CentOS give me good performance on Bhyve, but I have to say that "Everyday is a school day" :)

The last thing I'd like to ask to ziomario.
Why do you need Arch on Bhyve? (curiosity, professional reasons, etc.)
 
I have criticized Bhyve because I found some missing features and it's development is slow.
Just because you are of the opinion that some features might be missing does not mean that the bhyve developers are of the same opinion, and vice versa. It could be that they find bhyve feature wise quite complete because it does what they wanted to achieve, who knows.

Since bhyve is an opensource project it is of course always possible to get in touch with the developers and give them your ideas&feedback. What they are making out of it then is always an open question. Typical ways to get in touch with developers are - if existant - a bug tracker, mailing list or IRC channel.

Aside that I am pretty sure "development is slow" critic is understandable sometimes, but normally there are also pretty good reasons around for that which cannot easily be changed then.

Your statement by the way that bhyve does not support EFI variables is wrong. It supports them, but expects the file to be in the standard places with the standard name and is not looking for the location and file names many Linux distributions do use. Once it finds the file, it's able to save EFI variables. So quite the difference.

As solution you could for example create a feature request in the bug tracker to support such non standard areas and wait what happens.
 
To be honest I would not have bothered to install Arch on Bhyve until I read this topic. Working with Alpine, Debian and CentOS give me good performance on Bhyve, but I have to say that "Everyday is a school day" :)

The last thing I'd like to ask to ziomario.
Why do you need Arch on Bhyve? (curiosity, professional reasons, etc.)

I've tried to passthru my graphic card with several linux distributions because I've thought that the problem that I have with the pass thru could have depended also by the kernel used. Or,at least,I could have collected some more informations to understand how to fix the problem. So,I tried to install the nvidia driver on ubuntu,debian,fedora and arch. What I've found ? not so much. The error that I get is the same using different kernels (I have also compiled a very recent kernel). I've found also that if I use Fedora,bhyve does not accept the passhtru graphic slots at all.
 
Just because you are of the opinion that some features might be missing does not mean that the bhyve developers are of the same opinion, and vice versa. It could be that they find bhyve feature wise quite complete because it does what they wanted to achieve, who knows.

Since bhyve is an opensource project it is of course always possible to get in touch with the developers and give them your ideas&feedback. What they are making out of it then is always an open question. Typical ways to get in touch with developers are - if existant - a bug tracker, mailing list or IRC channel.

Aside that I am pretty sure "development is slow" critic is understandable sometimes, but normally there are also pretty good reasons around for that which cannot easily be changed then.

Your statement by the way that bhyve does not support EFI variables is wrong. It supports them, but expects the file to be in the standard places with the standard name and is not looking for the location and file names many Linux distributions do use. Once it finds the file, it's able to save EFI variables. So quite the difference.

As solution you could for example create a feature request in the bug tracker to support such non standard areas and wait what happens.

Yes,there are who does not think the same. But there are also who think the same as me. So,what ? Can I be with those who think like me ? My opinion is not isolated. I've found several developers who think that bhyve miss some (or in some cases,a lot) of features. You can think what you want. Me the same,right ? I'm already in touch with some developers and I have shared my PC with them,so that they can collect more informations to improve Bhyve. My critic is not sterile. I'm helping to make bhyve better. U can read below what David Schacther thinks about this :


at some point he says :

Aha! The UEFI firmware expects to find the bootloader in EFI/boot, not in EFI/debian. Typically, bootloader paths would be set as UEFI variables, but ----> bhyve is unable to store these between reboots.

How you want call this behavior if not a missing feature ? At this point,I'm asking to myself why you want defend bhyve and its developers at all costs at the cost of losing your intellectual honesty. Do you want the counter-proof
that the "uefi variables" was something to improve ? Check the link below and you will see that there is a work in progress that want to add the missing feature :

 
I've tried to passthru my graphic card with several linux distributions because I've thought that the problem that I have with the pass thru could have depended also by the kernel used. Or,at least,I could have collected some more informations to understand how to fix the problem. So,I tried to install the nvidia driver on ubuntu,debian,fedora and arch. What I've found ? not so much. The error that I get is the same using different kernels (I have also compiled a very recent kernel). I've found also that if I use Fedora,bhyve does not accept the passhtru graphic slots at all.
GPU passthru on Bhyve is a really challenge. I know more people fighting with the same thing
 
Yes,there are who does not think the same. But there are also who think the same as me. So,what ? Can I be with those who think like me ? My opinion is not isolated. I've found several developers who think that bhyve miss some (or in some cases,a lot) of features. You can think what you want. Me the same,right ? I'm already in touch with some developers and I have shared my PC with them,so that they can collect more informations to improve Bhyve. My critic is not sterile. I'm helping to make bhyve better. U can read below what David Schacther thinks about this :


at some point he says :

Aha! The UEFI firmware expects to find the bootloader in EFI/boot, not in EFI/debian. Typically, bootloader paths would be set as UEFI variables, but ----> bhyve is unable to store these between reboots.

How you want call this behavior if not a missing feature ? At this point,I'm asking to myself why you want defend bhyve and its developers at all costs at the cost of losing your intellectual honesty. Do you want the counter-proof
that the "uefi variables" was something to improve ? Check the link below and you will see that there is a work in progress that want to add the missing feature :

Y'know, there's still better ways to talk about it.

For example, instead of saying "There is no documentation for this feature", it's possible to say "I'm trying to do this, but I'm not finding usable documentation even after reading manuals and googling around". The second variant of the exact same message is more effective at inviting help for your problem, and increases the chances of finding a solution. You'll never know what you missed out on due to rudeness. I'm sorry, but you do come across as "Someone who knows everything for a fact, others should know that stuff, and owe it to me to share the knowledge and solve the problem I'm stuck on".

In your own words, "How you want call this behavior if not a missing feature ? ". This will invite defensive remarks like "Don't blame Bhyve.". Saying something like "Looks like Bhyve is not working the way I want it to" is far more likely to invite suggestions to try changing something in your config files, or to try a different distro or a different virtualization solution. Not all replies will solve your problem, but at least it's more likely that something useful will come your way if you change the tone of your posts.
 
How you want call this behavior if not a missing feature ? At this point,I'm asking to myself why you want defend bhyve and its developers at all costs at the cost of losing your intellectual honesty.
100% agreed with astyle (there's always a better way to talk about something). More important how you express yourself than the content ziomario

I understand what you meant but It looks you are in a pub or home with your close pals instead a FreeBSD forum chat.
 
You miss a little but very important detail,that I have told,but that did not make you comfortable to mention : that even if bhyve misses some features (a lot of developers tells that it lacks a lot of features,without worrying to use turns of words) I love bhyve anyway because what it can do, it does it well. The fact that you didn't mention this little detail painted me as an ungrateful person and for a person who criticizes and then abandon what he is doing. But I'm not an ungrateful or a destructive man. And I don't have to flatter anyone using pretty words. I love to call things by their name and usually I give my body and soul to complete a project and to collaborate. Yes, there are many ways to say something, to make it more acceptable, but using them depends on the situation and the type (or kind ?) of character / personality one has. The point is that,in my opinion, there is no need to make the description of a technical tool sweeter. It would have it instead if you were talking about a person who might feel hurted. But bhyve is not a person. And I'm sorry if there are those who love this tool so much and if they feel hurted if they hear someone else talking "badly" about it. But perhaps in this case it would be better if they do an examination of the situation to understood the reasons why they want to talk about it so delicately.
 
A solution has been provided to how you can boot Arch Linux under Bhyve with UEFI.

I think there is no point continue with this chip-chat, but I would like to conclude with some reflections:
  • Nothing has been personal. So don't it personal ziomario
  • It looks you don't want to listen and accept that some sentences you've used during this topic were no kind words/
  • Please don't repeat again and again about how you behave in your life ( remember Its no personal)
The bottom line.

You should consider "a wee bit", if different feedbacks from different people tell you the same thing. Probably you could learn something instead being "like a dog with the bone" saying "I'm right, you get wrong" or "I said nothing wrong".

Cheers
 
It is not good what you said. You can not ask me "don't go personal" if you made to me some personal considerations. If you make personal considerations about how it would be the best method for me to communicate, expect personal answers (it's not a revenge,it is somehow, a coherent answer). To be honest, you went more personally than I did. But for me it's ok. I'm sure that I haven't offended anynone.
 
This applies for quite many OS installation media, particularly Linux distro ISOs, that won't boot on bhyve via EFI. Even the final installed OS itself. I've encountered Linux distros that install a "branded" efi file, which then won't boot - unless you rename the EFI file.

The bootx64.efi is the one official location that UEFI looks at if there isn't any pre-existing NVRAM boot settings. If you have a boot problem, rename the EFI file to bootx64.efi and voila, it works.

Apologies if this seems off-topic to the PCI passthrough; it's just so easy to miss and hate bhyve for this otherwise small and easy to fix detail. I figured that merits spotlighting it more explicitly.

Very helpful advice! This works also for OpenSUSE.

In a post-install script for the efi file installed by OpenSUSE Tumbleweed, using a ZFS volume at zfs path VM_ZVOL for the guest VM image. As root, on the VM host machine

Code:
# mount_msdosfs /dev/zvol/${VM_ZVOL}p1 /mnt
# mkdir -p /mnt/EFI/BOOT
# cp -p /mnt/EFI/opensuse/grubx64.efi /mnt/EFI/BOOT/bootx64.efi
# umount /mnt

Here, VM_ZVOL=${VM_DIR}/${VM_NAME}/hd0, for VM_DIR=$(sysrc -qn vm_dir | cut -d: -f2) using the sysrc config for vm-bhyve on ZFS => zroot/opt/bhyve/vm in the scripting, for vm_dir=zfs:zroot/opt/bhyve/vm in rc.conf

The VM_NAME would be the vm-bhyve VM name for the OpenSUSE VM, "mezzo" locally => zroot/opt/bhyve/vm/mezzo/hd0

Of course, if not using ZFS then mdconfig could be used before the mount_msdosfs cmd, with file pathnames adjusted to suit the host config.

The OpenSUSE installation is bootable now. Thx!
 
It is not good what you said. You can not ask me "don't go personal" if you made to me some personal considerations. If you make personal considerations about how it would be the best method for me to communicate, expect personal answers (it's not a revenge,it is somehow, a coherent answer). To be honest, you went more personally than I did. But for me it's ok. I'm sure that I haven't offended anynone.
This might be just language differences between English and Italian speakers, connotations of the word "Personal", and what gets more emphasis. "Technical details of the device I own" can be looked at as "personal details" - or not, depending on context. For example, I don't want anyone looking at my phone for technical details, but I'd proudly share that the phone has a Samsung Exynos 7884...
 
Back
Top