Re: [libvirt] [PATCHv2 1/2] bhyve: Support /domain/bootloader configuration for non-FreeBSD guests.
On Fri, Oct 24, 2014 at 03:28:33PM -0700, Craig Rodrigues wrote: On Fri, Oct 24, 2014 at 6:11 AM, Conrad Rad cse@gmail.com wrote: Any idea how soon? Months? A year? 5 years? I'm not comfortable postponing improvements indefinitely for vaporware. In the wonderful bhyve-UEFI future, we can ignore/warn about bootloader. Hi, I have to agree with Conrad here. I hope that any perceived future direction of bhyve is not going to be used as an excuse to block some of the libvirt patches that Conrad is submitting. The stuff that Conrad is working on overlaps some of the shortcomings in libvirt/bhyve that I mentioned here: https://lists.freebsd.org/pipermail/freebsd-virtualization/2014-October/002857.html Fixing these issues in libvirt will make libvirt + bhyve more usable today. When the bhyve-UEFI stuff comes out in future, that will be even better, Libvirt has a goal that we never break application compatibility, which includes the way the XML is configured for guests. So when reviewing patches like this series it is important to try to have an awareness of what further patches may be coming down the pipe in the future, so we can avoid painting ourselves into a corner. So this question of Roman's isn't really about blocking patches for future vapourware, but rather about making sure that decisions we make today don't cause us undue problems with UEFI does arrive at some point later. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: NATed or Private Network Setups
On Friday, October 24, 2014 04:08:27 PM Pete Wright wrote: Hi All, Has anyone deployed bhyve using NAT'd or private network setups? I've been able to deploy bridged interfaces, but I was wondering if anyone has done other network topologies. Is there anything preventing this from happening code wise? I reckon it could be achieved by creating a pseudo interface? I setup a bridge on my laptop and add all the tap interfaces for VMs as members to the bridge. I use a /24 for the internal LAN for these interfaces and assign the .1 to the bridge0 interface itself. I then run dnsmasq to provide DHCP/DNS to the VMs and use natd (ipfw_nat would also work) to allow the VMs NAT access to the outside world. There are more details in an article in the most recent issue of the FreeBSD Journal, but I'll push that into the regular FreeBSD docs at some point as well. With the dnsmasq setup, I put the vmname as the hostname so that it is sent in the dhclient request. dnsmasq then adds local overrides for VMs while they are active. (So you can 'ssh vm0' on the host, or from another vm.) The 'host' entry in /etc/hosts is also snarfed up by dnsmasq so that within a vm I can use 'host' as a hostname (e.g. for NFS mounting something off of my laptop). Some config file snippets: /etc/sysctl.conf: net.link.tap.up_on_open=1 /etc/rc.conf: # bhyve setup autobridge_interfaces=bridge0 autobridge_bridge0=tap* cloned_interfaces=bridge0 tap0 tap1 tap2 ifconfig_bridge0=inet 192.168.16.1/24 gateway_enable=YES natd_enable=YES natd_interface=wlan0 dnsmasq_enable=YES firewall_enable=YES firewall_type=/etc/rc.firewall.pippin /etc/hosts: 192.168.16.1host /etc/resolvconf.conf: name_servers=127.0.0.1 dnsmasq_conf=/etc/dnsmasq-conf.conf dnsmasq_resolv=/etc/dnsmasq-resolv.conf /usr/local/etc/dnsmasq.conf: domain-needed bogus-priv resolv-file=/etc/dnsmasq-resolv.conf interface=bridge0 dhcp-range=192.168.16.10,192.168.16.200,12h conf-file=/etc/dnsmasq-conf.conf /etc/rc.firewall.pippin: # prevent inbound traffic for our guest /24 add denyall from any to 192.168.16.0/24 via em0 add denyall from any to 192.168.16.0/24 via wlan0 # divert packets between guest and outside world to natd add divert natd all from any to any via wlan0 # prevent outbound traffic for our guest /24 add denyall from 192.168.16.0/24 to any via em0 add denyall from 192.168.16.0/24 to any via wlan0 # pass everything else add allow all from any to any (I have not figured out a way to have the NAT prefer em0 if present and fail over to wlan0 if not, etc.) -- John Baldwin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Rework hypervisor detection
Hi John, I don't have access to phabricator so I'll try and review in email. +#ifdef XEN +int vm_guest = VM_GUEST_XEN; +#else +int vm_guest = VM_GUEST_NO; /* Running as virtual machine guest? */ +#endif The whitespace between 'int' and 'vm_guest' in the second line seems wrong (extra space?). For vmware_hvcall() in x86/include/vmware.h, are you sure the inline assembly is correct? Have you tried the detection on a VMware VM? VMware's documentation specifies the arguments in a different order[0], and at Isilon when we tried the port-based detection in a slightly older revision of CURRENT, it didn't work (IIRC). Everything else looks good to me, thanks. [0]: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009458 Best, Conrad ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Rework hypervisor detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-10-27 12:47:13 -0400, Conrad Meyer wrote: Hi John, I don't have access to phabricator so I'll try and review in email. +#ifdef XEN +int vm_guest = VM_GUEST_XEN; +#else +int vm_guest = VM_GUEST_NO; /* Running as virtual machine guest? */ +#endif The whitespace between 'int' and 'vm_guest' in the second line seems wrong (extra space?). For vmware_hvcall() in x86/include/vmware.h, are you sure the inline assembly is correct? Have you tried the detection on a VMware VM? VMware's documentation specifies the arguments in a different order[0], and at Isilon when we tried the port-based detection in a slightly older revision of CURRENT, it didn't work (IIRC). Everything else looks good to me, thanks. [0]: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009458 I wrote the code and it worked for me at the time. I'll try again soon. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEbBAEBAgAGBQJUTn39AAoJEHyflib82/FGWt8H+IoPF03arSi2lAgT+LnVrKgj x+r/yKfQ4+5/nxwRfvu/6FER+AUCWRYt+C12vnYdJwpx4iyspNi9FLDgyqpgtmgA FQQr1ZYuOG8fHDln5gGxXG8p3VQBce5zaVHK7CHaLrgPMM1qY6OE35aSplzCIpsH 9QmlokW5gjaPvCt/EdCnbHB3nBZ2O8gpkd1GCr4OZwNerkmUmDL3dM08DgKVQsED eeYhOKP6e4cLNG/1VGLqcMpMH93CYFmukOcLMpiNNaFwC2zEusah6X5e98bzeVxk HcgMvB451OWEVoM93CoV86q3DTlxRthpwnuB06LfSDHSZRrRO4IqYR9Sj3OYFQ== =/9eJ -END PGP SIGNATURE- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: NATed or Private Network Setups
On 10/27/14 09:21, John Baldwin wrote: On Friday, October 24, 2014 04:08:27 PM Pete Wright wrote: Hi All, Has anyone deployed bhyve using NAT'd or private network setups? I've been able to deploy bridged interfaces, but I was wondering if anyone has done other network topologies. Is there anything preventing this from happening code wise? I reckon it could be achieved by creating a pseudo interface? I setup a bridge on my laptop and add all the tap interfaces for VMs as members to the bridge. I use a /24 for the internal LAN for these interfaces and assign the .1 to the bridge0 interface itself. I then run dnsmasq to provide DHCP/DNS to the VMs and use natd (ipfw_nat would also work) to allow the VMs NAT access to the outside world. There are more details in an article in the most recent issue of the FreeBSD Journal, but I'll push that into the regular FreeBSD docs at some point as well. With the dnsmasq setup, I put the vmname as the hostname so that it is sent in the dhclient request. dnsmasq then adds local overrides for VMs while they are active. (So you can 'ssh vm0' on the host, or from another vm.) The 'host' entry in /etc/hosts is also snarfed up by dnsmasq so that within a vm I can use 'host' as a hostname (e.g. for NFS mounting something off of my laptop). Some config file snippets: /etc/sysctl.conf: net.link.tap.up_on_open=1 /etc/rc.conf: # bhyve setup autobridge_interfaces=bridge0 autobridge_bridge0=tap* cloned_interfaces=bridge0 tap0 tap1 tap2 ifconfig_bridge0=inet 192.168.16.1/24 gateway_enable=YES natd_enable=YES natd_interface=wlan0 dnsmasq_enable=YES firewall_enable=YES firewall_type=/etc/rc.firewall.pippin /etc/hosts: 192.168.16.1host /etc/resolvconf.conf: name_servers=127.0.0.1 dnsmasq_conf=/etc/dnsmasq-conf.conf dnsmasq_resolv=/etc/dnsmasq-resolv.conf /usr/local/etc/dnsmasq.conf: domain-needed bogus-priv resolv-file=/etc/dnsmasq-resolv.conf interface=bridge0 dhcp-range=192.168.16.10,192.168.16.200,12h conf-file=/etc/dnsmasq-conf.conf /etc/rc.firewall.pippin: # prevent inbound traffic for our guest /24 add denyall from any to 192.168.16.0/24 via em0 add denyall from any to 192.168.16.0/24 via wlan0 # divert packets between guest and outside world to natd add divert natd all from any to any via wlan0 # prevent outbound traffic for our guest /24 add denyall from 192.168.16.0/24 to any via em0 add denyall from 192.168.16.0/24 to any via wlan0 # pass everything else add allow all from any to any (I have not figured out a way to have the NAT prefer em0 if present and fail over to wlan0 if not, etc.) Thanks for this detailed explanation John! Using dnsmasq sounds great, especially for my environment since we already leverage it for openstack on our linux systems extensively. Cheers, -pete -- Pete Wright p...@nomadlogic.org twitter = @nomadlogicLA ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Rework hypervisor detection
On Monday, October 27, 2014 12:47:13 PM Conrad Meyer wrote: Hi John, I don't have access to phabricator so I'll try and review in email. +#ifdef XEN +int vm_guest = VM_GUEST_XEN; +#else +int vm_guest = VM_GUEST_NO; /* Running as virtual machine guest? */ +#endif The whitespace between 'int' and 'vm_guest' in the second line seems wrong (extra space?). Yep, fixed. For vmware_hvcall() in x86/include/vmware.h, are you sure the inline assembly is correct? Have you tried the detection on a VMware VM? VMware's documentation specifies the arguments in a different order[0], and at Isilon when we tried the port-based detection in a slightly older revision of CURRENT, it didn't work (IIRC). I don't have VMware handy, but it is a simple copy and paste of existing code in tsc.c. -- John Baldwin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Rework hypervisor detection
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-10-27 13:16:45 -0400, Jung-uk Kim wrote: 2014년 10월 27일 13:16에 Jung-uk Kim 이(가) 쓴 글: On 2014-10-27 12:47:13 -0400, Conrad Meyer wrote: Hi John, I don't have access to phabricator so I'll try and review in email. +#ifdef XEN +int vm_guest = VM_GUEST_XEN; +#else +int vm_guest = VM_GUEST_NO; /* Running as virtual machine guest? */ +#endif The whitespace between 'int' and 'vm_guest' in the second line seems wrong (extra space?). For vmware_hvcall() in x86/include/vmware.h, are you sure the inline assembly is correct? Have you tried the detection on a VMware VM? VMware's documentation specifies the arguments in a different order[0], and at Isilon when we tried the port-based detection in a slightly older revision of CURRENT, it didn't work (IIRC). Everything else looks good to me, thanks. [0]: http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1009458 I wrote the code and it worked for me at the time. I'll try again soon. I just tested the function and it still works well. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJUTo9cAAoJEHyflib82/FGLOAIAJYFN2KVlaLgmVTtOX5uU/yf gjazSIRLzQopS/yMUDvZ0hSJovoqFtHpUHTWwIMhqbpKD0u2OehTVWrt+frYrrG1 R0DHlWXIeBkfgdp3fD/6jW5Bbq1yNidn6arquSbbhxLROOTkuE0jiHUHYhgkD89a ZluWuHfuNCPrAYEfLKAOs739ocQO+xZe+jeS2lae74bSgE06kRnQgx72Cv7ZZU35 l3C152sJKuDR+P9DOxi/mLdWcNXO76YFXkmt2JvIey2FUsw3fCIYXbN0FOz/dWD6 q8DaSCWjxYHs1TLPCueBrOgOyIzDQ5Ky4l1V/8aBROigtgmVsxv0U/rKZO5pSSs= =dG0n -END PGP SIGNATURE- ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: Automatically running /usr/tests on stable/10 branch under Jenkins
Susan, In addition to the slides which I previously mentioned, you and your colleagues at Xinuos may wish to take a quick read of this document which I wrote, the Kyua Quickstart Guide: https://github.com/rodrigc/kyua/wiki/Quickstart-Guide kyua is the test harness that is used to run the tests in the /usr/tests directory in FreeBSD. That doc is a very quick guide on how to run tests under kyua, and also how to write tests which can be run under kyua. Getting any feedback on this would be very useful. Does that doc make sense to a newcomer? Are there typos? I want the FreeBSD project to get to the point where: (1) anybody can download the FreeBSD tests (2) anybody can run the tests (3) people can easily figure out how to write new tests and contribute them back (if they wish) to FreeBSD Better documentation will hopefully help with this. Thanks. -- Craig On Fri, Oct 24, 2014 at 1:37 PM, Susan Stanziano susan.stanzi...@xinuos.com wrote: Hello Craig, I have been reading through your slides and your website announcement, as requested, and have a few questions. (I have also subscribed to the mailing list as suggested). (1) The slides indicate that with a FreeBSD10 and lower OS, I should be able to build tests already included with FreeBSD. I have created a VM on FreeBSD10.0 but do not have the /etc/make.conf file necessary to build and install the tests. This may be that I am missing some set-up steps required but not covered in the slide presentation. (2) Does the test build require the use of the Build Flow Plugin or can the tests be run independent of the continuous build model? (3) Can the tests only be run under Bhyve as described in the announcement? I would be happy to exchange emails with you or skype as I investigate this work further. Regards, Susan -- *From: *Craig Rodrigues rodr...@freebsd.org *To: *e...@xinuos.com *Cc: *Allan Jude allanj...@freebsd.org, John Wolfe j...@xinuos.com, freebsd-virtualization@freebsd.org, freebsd-test...@freebsd.org, Susan Stanziano susan.stanzi...@xinuos.com, Cheryl Blain cheryl.bl...@xinuos.com, Andy Nagle andrew.na...@xinuos.com *Sent: *Friday, October 24, 2014 7:09:04 AM *Subject: *Re: Re: Automatically running /usr/tests on stable/10 branch under Jenkins On Fri, Oct 24, 2014 at 1:11 AM, Eric le Blan e...@xinuos.com wrote: Allan, Always happy to discuss testing. I believe that Susan Stanziono of Xinuos system test team already spoke to some of you. Please do not hesitate to reach her for any specific needs. Also, Cheryl Blain - Xinuos VP of operations - will be at the MeetBSD vendor summit on Nov 3-4 and can reach to Craig. It would be helpful if someone (or some people) from Xinuous could do the following: (1) Subscribe to freebsd-test...@freebsd.org at https://lists.freebsd.org/mailman/listinfo/freebsd-testing to start monitoring the discussions on that list. (2) Review this announcement: http://jenkins-ci.org/content/freebsd-project-use-jenkins-os-testing (3) Review these slides: http://www.slideshare.net/CraigRodrigues1/kyua-jenkins (4) Talk to me at MeetBSD Vendor Summit I have not been given a long timeslot to give a presentation, so reviewing those links before MeetBSD would be helpful. Long term, any testing of FreeBSD will only succeed if there is an ecosystem of people working together and sharing common scripts and information for testing FreeBSD. Any help that Xinuous (or any other company) can provide would be welcome. -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
