Outdated grub2-bhyve and booting Centos7
Dear Colleagues, Can I draw your attention to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230453 please? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ 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: Passthrough not working with OpenBSD nor NetBSD
How does KVM and VMware solve that? I haven't tried PCI passthrough with them, but I assume that it works..? On Thu, Aug 9, 2018, 18:24 John Baldwin wrote: > On 8/8/18 11:08 AM, Farid Joubbi wrote: > > That's what I also thought, but it's not anything I can force it to do, > is it? Isn't it supposed to detect the MSI interrupt compatibility > automatically? > > Apparently Open/Net always try to setup INTx before trying MSI even if they > won't use INTx per the commit log in revision 280725. We could perhaps try > to provide a "fake" INTx interrupt that doesn't work, but I'll have to > think > about how to implement that. > > -- > John Baldwin > ___ 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: Passthrough not working with OpenBSD nor NetBSD
On 8/8/18 11:08 AM, Farid Joubbi wrote: > That's what I also thought, but it's not anything I can force it to do, is > it? Isn't it supposed to detect the MSI interrupt compatibility automatically? Apparently Open/Net always try to setup INTx before trying MSI even if they won't use INTx per the commit log in revision 280725. We could perhaps try to provide a "fake" INTx interrupt that doesn't work, but I'll have to think about how to implement that. -- John Baldwin ___ 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: Why can't I dtrace processes running in a jail from the host?
On Thu, Aug 09, 2018 at 01:09:00PM +0200, Patrick M. Hausen wrote: > Hi all, > > I'm wondering why on a busy hosting server with hundreds of PHP-FPM > workers running in jails "dtrace -l" on the host does not show any > PHP specific probes. PHP *is* compiled with dtrace support for all the > jails. > > Enabling /dev/dtrace/* via devfs.rules for a specific jail and then repeating > the process *inside* the jail works as expected. > > Shouldn't jailed processes be transparently visible from the host system > but not vice versa? For userland static probes to be globally visible, the process needs to register them with the kernel when it starts. This is done automatically using a constructor which issues ioctls to /dev/dtrace/helper, hence the requirement for /dev/dtrace/* in the jail. In general it is still possible to use unregistered userland probes in this scenario: dtrace(1) can discover them when it attaches to a specified process. I'm not sure how well this will work if the process is jailed and dtrace(1) is invoked on the host, but it's worth trying. I would be rather wary of enabling access to /dev/dtrace/* in a jail. The kernel code which parses probe metadata has a large attack surface and has had security holes in the past. ___ 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"
Why can't I dtrace processes running in a jail from the host?
Hi all, I'm wondering why on a busy hosting server with hundreds of PHP-FPM workers running in jails "dtrace -l" on the host does not show any PHP specific probes. PHP *is* compiled with dtrace support for all the jails. Enabling /dev/dtrace/* via devfs.rules for a specific jail and then repeating the process *inside* the jail works as expected. Shouldn't jailed processes be transparently visible from the host system but not vice versa? Thanks, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
[Bug 230082] bhyve doesn't set process title
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230082 --- Comment #11 from Mariusz Zaborski --- This wasn't integrated yet to the 11. I will do this today. Thanks. -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 230082] bhyve doesn't set process title
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230082 Nikita Olenets changed: What|Removed |Added CC||z...@zeon.kiev.ua --- Comment #10 from Nikita Olenets --- (In reply to Yuichiro NAITO from comment #9) Hello, Looks like the issue is exist still. 09:27:34)27[root@host ~]# ps wwax | grep Test01 3148 0 Is+ 0:00,04 /bin/sh /usr/local/sbin/vm -tf _run Test01 5531 0 SC+ 1:43,20 bhyve -c 1 -m 2G -AHP -U 7f86c10b-d8c9-11e7-ae5d-f04da2090b7b -u -s 0,hostbridge -s 31,lpc -s 4:0,virtio-blk,/usr/local/VM/ Test01 /disk0.img -s 5:0,virtio-net,tap1102,mac=58:9c:fc:07:1a:8b -l com1,stdio Test01 (09:27:40)27[root@host ~]# uname -a FreeBSD host.local.org 11.2-STABLE FreeBSD 11.2-STABLE #18 r337452: Wed Aug 8 15:06:59 EEST 2018 r...@host.local.org:/usr/obj/usr/src/sys/CUSTOM amd64 = OLDER BEHAVIOR = Comparing to the older system ( r335977 ) (09:31:30)4[root@bohus docs]# ps wwax | grep Ubuntu 5053 1 IC+115:04,09 bhyve: Ubuntu (bhyve) (09:31:37)4[root@bohus docs]# uname -a FreeBSD bohus 11.2-STABLE FreeBSD 11.2-STABLE #7 r335977: Fri Jul 6 06:58:35 EEST 2018 root@bohus:/usr/obj/usr/src/sys/CUSTOM amd64 -- You are receiving this mail because: You are the assignee for the bug. ___ 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: [Bug 230082] bhyve doesn't set process title
Hello,
Looks like the issue is exist still.
09:27:34)27[root@host ~]# ps wwax | grep Test01
3148 0 Is+ 0:00,04 /bin/sh /usr/local/sbin/vm -tf _run Test01
5531 0 SC+ 1:43,20 bhyve -c 1 -m 2G -AHP -U
7f86c10b-d8c9-11e7-ae5d-f04da2090b7b -u -s 0,hostbridge -s 31,lpc -s
4:0,virtio-blk,/usr/local/VM/ Test01 /disk0.img -s
5:0,virtio-net,tap1102,mac=58:9c:fc:07:1a:8b -l com1,stdio Test01
(09:27:40)27[root@host ~]# uname -a
FreeBSD host.local.org 11.2-STABLE FreeBSD 11.2-STABLE #18 r337452: Wed
Aug 8 15:06:59 EEST 2018 r...@host.local.org:/usr/obj/usr/src/sys/CUSTOM
amd64
=
Comparing to the older system ( r335977 )
(09:31:30)4[root@bohus docs]# ps wwax | grep Ubuntu
5053 1 IC+115:04,09 bhyve: Ubuntu (bhyve)
(09:31:37)4[root@bohus docs]# uname -a
FreeBSD bohus 11.2-STABLE FreeBSD 11.2-STABLE #7 r335977: Fri Jul 6
06:58:35 EEST 2018 root@bohus:/usr/obj/usr/src/sys/CUSTOM amd64
On Fri, Aug 3, 2018 at 8:25 AM, wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230082
>
> Yuichiro NAITO changed:
>
>What|Removed |Added
>
>
> Status|In Progress |Closed
> Resolution|--- |FIXED
>
> --- Comment #9 from Yuichiro NAITO ---
> (In reply to Mariusz Zaborski from comment #7)
> > The setproctitle(3) looks fine with me - I will commit it.
>
> Thanks for the commit.
>
> > With the ps_string the problem is a little more complicated.
> > In my opinion the title is a part of a global namespace so we should not
> be ab\
> le to change it but I would like to discussed this.
>
> I misunderstood sysctl behavior.
>
> I saw that original (before r335939) setproctitle(3) calls sysctl like
> this.
>
> ```
> sysctl([CTL_KERN, KERN_PROC, KEN_PROC_ARGS, getpid()], ...)
> ```
>
> This code works in capability mode all the time (independent of r335939).
> I thought calling sysctl("kern.ps_strings") was also safe in capability
> mode.
> But, the sysctl is allowed to write only...
>
> > In this bug report can we only focus on the bhyve title issue?
>
> Yes, I don't see any other problems for now.
> I will close this PR.
>
> Thank you!
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.
> ___
> 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"
>
--
Nikita Olenets
___
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"
