Re: Report of my virtual network lab migrated from virtualbox to bhyve
Trying this again. First attempt went only to Sami. I think it's awesome that there are projects using FreeBSD technology. However, this list is for discussions related to virtualization in FreeBSD. IMO, there has been a lot of off-topic posts on this list lately, mostly by Aryeh. If I wanted this level of information about Petitecloud, I'd subscribe to their list (now that they have one). And if I wanted to know about some persons plans which are not directly related to virtualization in FreeBSD, I'd ask them, or look at their blog. These things are not the reason I subscribed to this list, at least. _ Marie Helene http://savagedlight.me/ On Sun, Feb 9, 2014 at 8:25 AM, Sami Halabi sodyn...@gmail.com wrote: As long as its practical and related to the virtualizationn I think its okay. At least he provides a lot of info through his discussions. Sami בתאריך 9 בפבר 2014 01:28, Michael Dexter edi...@callfortesting.org כתב: For the curious, Aryeh posted 67 out of January's 276 messages to the list with the next highest poster coming in at 21. This is not the proper use of this list. Michael Dexter bhyve volunteer ___ 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 ___ 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 ___ 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: CFT: bhyve AMD snapshot
On 8-2-2014 21:36, Michael Dexter wrote: Hello all, I have built and uploaded a bhyve SVM project branch snapshot of r261578 (February 4th, 2014, MFC @ r259205) that can be found at: http://mirrors.nycbug.org/pub/bhyve/r261578-svm/ Those with Barcelona class (http://en.wikipedia.org/wiki/AMD_10h) AMD hardware are invited to give this. So far I have had luck with my humble Athlon(tm) II Neo N36L Dual-Core Processor (1297.87-MHz K8-class CPU). I was exactly looking for this information, since I upgraded to 10-Stable. And found no bhyve for AMD. Are there any (near future) plans to merge this with the regular stable branch? For now I'll give the above a testshot. Thanx, --WjW ___ 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
Detect of BHyve VM was powered off or rebooted?
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A} ${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
Thanks for any advice.
--
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
Re: Detect of BHyve VM was powered off or rebooted?
On Sun, Feb 9, 2014 at 4:11 PM, Craig Rodrigues rodr...@freebsd.org wrote:
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A} ${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
Thanks for any advice.
The options you gave (which are really the only ones available) do not
distinguish between the reason for the termination of the instance of bhyve
pointing to /dev/vmm/XXX (it just does a normal termination). In my
playing with this for almost a month the only solution seems to be put a
trigger on instance shutdown via whatever method to leave a cookie file
behind on the host (note I have not nor plan to do this in any of my own
work). An other question is it wise to auto-reboot regardless of reason of
the hypervisor termination?
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
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: Detect of BHyve VM was powered off or rebooted?
On Sun, Feb 9, 2014 at 5:18 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Feb 9, 2014 at 1:32 PM, Aryeh Friedman
aryeh.fried...@gmail.comwrote:
On Sun, Feb 9, 2014 at 4:11 PM, Craig Rodrigues rodr...@freebsd.orgwrote:
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s
1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A}
${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
Thanks for any advice.
The options you gave (which are really the only ones available) do not
distinguish between the reason for the termination of the instance of bhyve
pointing to /dev/vmm/XXX (it just does a normal termination).
Did you play with any of these flags to bhyvectl?
[--get-vmcs-exit-ctls]
[--get-vmcs-exit-reason]
[--get-vmcs-exit-qualification]
[--get-vmcs-exit-interruption-info]
If I do:
bhyvectl --get-vmcs-exit-reason --vm vm1
I get:
vmcs_exit_reason[0] 0x001e
If I look at:
http://svnweb.freebsd.org/base/head/sys/amd64/vmm/intel/vmcs.h?view=markup#l310
we have:
#define EXIT_REASON_INOUT 30
You will likely need to detect the following ones also (all for different
reasons that may or may not have anything to do with an issue with the VM
instead of some host [OS or hardware] issue):
#define EXIT_REASON_EXT_INTR 1
#define EXIT_REASON_INIT 3
#define EXIT_REASON_HLT 12
#define EXIT_REASON_CPUID 10
#define EXIT_REASON_VMLAUNCH 20
Linux has this stuff also:
http://lxr.free-electrons.com/source/arch/x86/include/asm/vmx.h?v=3.1#L250
so I guess these values are defined in some Intel manual.
In my playing with this for almost a month the only solution seems to be
put a trigger on instance shutdown via whatever method to leave a cookie
file behind on the host (note I have not nor plan to do this in any of my
own work).
Yes, I can see why this might need to be done. I might need to do that
myself. However, if bhyvectl can be used to provide adequate status
information as to why the VM exited, I might be able to avoid this.
It would be nicer though if /usr/sbin/bhyve returned
the EXIT_REASON in its status code.
An other question is it wise to auto-reboot regardless of reason of the
hypervisor termination?
I think the answer is it depends. If someone
does reboot or shutdown -r, I think it is reasonable to restart the
VM. If someone does halt -p or shutdown -p, I think it is reasonable
to not restart the VM. For any other error condition, I think it is
reasonable to not restart the VM.
I think that there is no single answer for all users and all applications.
In my case, I am running BHyve VM's as headless which
I access via the /dev/nmdm driver. If the VM reboots normally, I want it
to restart.
It seems almost any boot failure would be host side for example if there is
no SSH access (which if the instance is never logged into then it is likely
a host issue) then it is highly unlikely the VM is in bootable form (this
is after a manual reboot of it)... an other reason (just learned the
hardway) is the user uses a mismatch between backing file formats (my case
using raw images with ahci-hd)
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
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: RFC: hyperv disk i/o performance vs. data integrity
On Sat, Feb 1, 2014 at 9:24 PM, Aryeh Friedman aryeh.fried...@gmail.comwrote: Craig Rodrigues and the FreeNAS team have done a fantastic job already (I have not personally tried FreeNAS yet but I have heard nothing but good things about it) and making it so it can run on a bhyve instance. Thanks for those kind words. At the 2013 FreeBSD Vendor Summit, I gave this presentation: http://www.ixsystems.com/whats-new/jenkins-bhyve-and-webdriver-continuous-integration-testing-on-freenas/ which shows how I am using BHyve to test FreeNAS. BHyve is rough around the edges, but it works really well for testing. BHyve is improving every day. I encourage anyone in the BHyve community to download a FreeNAS 9.2.1 ISO and test booting it inside a BHyve VM. See this link for download details: http://forums.freenas.org/threads/announcing-freenas-9-2-1-release.18278/ Booting the FreeNAS ISO inside BHyve is a great way to test out BHyve (and FreeNAS). If you find FreeNAS-specific problems you can report them at: http://www.freenas.org/support/ That web page has links to our bugtracker and online forums. That way there is no need to clutter this mailing list with FreeNAS-specific stuff. -- 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
Re: Detect of BHyve VM was powered off or rebooted?
Hi Craig,
On Sun, Feb 9, 2014 at 1:11 PM, Craig Rodrigues rodr...@freebsd.org wrote:
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A} ${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
The exit code of the bhyve process will be 0 if it exited because the
guest rebooted and will be non-zero if the guest did an acpi poweroff.
You can use that to distinguish between cases (2) and (3).
Having said that there are error conditions for which bhyve exits with
a non-zero exit code. So, we'll need to explicitly define an exit code
to distinguish between an acpi poweroff and these error conditions.
best
Neel
Thanks for any advice.
--
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
___
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: Detect of BHyve VM was powered off or rebooted?
Hi Craig,
On Sun, Feb 9, 2014 at 2:18 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Feb 9, 2014 at 1:32 PM, Aryeh Friedman
aryeh.fried...@gmail.comwrote:
On Sun, Feb 9, 2014 at 4:11 PM, Craig Rodrigues rodr...@freebsd.orgwrote:
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s 1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A} ${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
Thanks for any advice.
The options you gave (which are really the only ones available) do not
distinguish between the reason for the termination of the instance of bhyve
pointing to /dev/vmm/XXX (it just does a normal termination).
Did you play with any of these flags to bhyvectl?
[--get-vmcs-exit-ctls]
[--get-vmcs-exit-reason]
[--get-vmcs-exit-qualification]
[--get-vmcs-exit-interruption-info]
If I do:
bhyvectl --get-vmcs-exit-reason --vm vm1
I get:
vmcs_exit_reason[0] 0x001e
If I look at:
http://svnweb.freebsd.org/base/head/sys/amd64/vmm/intel/vmcs.h?view=markup#l310
we have:
#define EXIT_REASON_INOUT 30
Linux has this stuff also:
http://lxr.free-electrons.com/source/arch/x86/include/asm/vmx.h?v=3.1#L250
so I guess these values are defined in some Intel manual.
Yes, but this an entirely different thing. The VMCS exit reason is
used to inform the hypervisor what condition caused the guest to stop
executing - e.g. a nested page fault.
Please don't use it to infer whether the guest wanted to reboot or poweroff :-)
In my playing with this for almost a month the only solution seems to be
put a trigger on instance shutdown via whatever method to leave a cookie
file behind on the host (note I have not nor plan to do this in any of my
own work).
Yes, I can see why this might need to be done. I might need to do that
myself. However, if bhyvectl can be used to provide adequate status
information as to why the VM exited, I might be able to avoid this.
It would be nicer though if /usr/sbin/bhyve returned
the EXIT_REASON in its status code.
Agreed - see my reply to your original post.
best
Neel
An other question is it wise to auto-reboot regardless of reason of the
hypervisor termination?
I think the answer is it depends. If someone
does reboot or shutdown -r, I think it is reasonable to restart the
VM. If someone does halt -p or shutdown -p, I think it is reasonable
to not restart the VM. For any other error condition, I think it is
reasonable to not restart the VM.
I think that there is no single answer for all users and all applications.
In my case, I am running BHyve VM's as headless which
I access via the /dev/nmdm driver. If the VM reboots normally, I want it
to restart.
--
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
___
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: Detect of BHyve VM was powered off or rebooted?
Hi Aryeh,
On Sun, Feb 9, 2014 at 2:34 PM, Aryeh Friedman aryeh.fried...@gmail.com wrote:
On Sun, Feb 9, 2014 at 5:18 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Feb 9, 2014 at 1:32 PM, Aryeh Friedman
aryeh.fried...@gmail.comwrote:
On Sun, Feb 9, 2014 at 4:11 PM, Craig Rodrigues rodr...@freebsd.orgwrote:
Hi,
I posted some rc.d scripts that I am using to boot a BHyve VM
and send the output to a serial console using the /dev/nmdm
driver:
http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/002040.html
It works quite well. There is some things I would like to improve,
and would like some advice on the best way to do it.
(1) If the VM was destroyed with bhyvectl --destroy --vm ${VM_NAME},
then I do not want to automatically restart the VM in the script.
User should manually: service bhyvevm start
(2) If the VM was powered down, via shutdown -p, or halt -p,
then in my script I do not want to restart the VM in the script.
User should manually: service bhyvevm start
(3) If the VM was rebooted via reboot or shutdown -r,
then I *do* want the script to restart the VM.
I think if I change my start_vm.sh script to do something like:
(
while [ -e /dev/vmm/${VM} ]; do
/usr/sbin/bhyve -c 16 -m 8G -A -H -P -g 0 -s 0:0,hostbridge -s
1:0,lpc
-s 2:0,virtio-net,${TAP} -s 3:0,virtio-blk,${IMG} -l com1,${CONS_A}
${VM}
done
)
then this might cover cases (1) and (3), but what will cover
case (2)?
Thanks for any advice.
The options you gave (which are really the only ones available) do not
distinguish between the reason for the termination of the instance of bhyve
pointing to /dev/vmm/XXX (it just does a normal termination).
Did you play with any of these flags to bhyvectl?
[--get-vmcs-exit-ctls]
[--get-vmcs-exit-reason]
[--get-vmcs-exit-qualification]
[--get-vmcs-exit-interruption-info]
If I do:
bhyvectl --get-vmcs-exit-reason --vm vm1
I get:
vmcs_exit_reason[0] 0x001e
If I look at:
http://svnweb.freebsd.org/base/head/sys/amd64/vmm/intel/vmcs.h?view=markup#l310
we have:
#define EXIT_REASON_INOUT 30
You will likely need to detect the following ones also (all for different
reasons that may or may not have anything to do with an issue with the VM
instead of some host [OS or hardware] issue):
#define EXIT_REASON_EXT_INTR 1
#define EXIT_REASON_INIT 3
#define EXIT_REASON_HLT 12
#define EXIT_REASON_CPUID 10
#define EXIT_REASON_VMLAUNCH 20
These are VMCS exit reasons that have nothing to do whatsoever with
the guest wanting to reboot or power itself off.
best
Neel
Linux has this stuff also:
http://lxr.free-electrons.com/source/arch/x86/include/asm/vmx.h?v=3.1#L250
so I guess these values are defined in some Intel manual.
In my playing with this for almost a month the only solution seems to be
put a trigger on instance shutdown via whatever method to leave a cookie
file behind on the host (note I have not nor plan to do this in any of my
own work).
Yes, I can see why this might need to be done. I might need to do that
myself. However, if bhyvectl can be used to provide adequate status
information as to why the VM exited, I might be able to avoid this.
It would be nicer though if /usr/sbin/bhyve returned
the EXIT_REASON in its status code.
An other question is it wise to auto-reboot regardless of reason of the
hypervisor termination?
I think the answer is it depends. If someone
does reboot or shutdown -r, I think it is reasonable to restart the
VM. If someone does halt -p or shutdown -p, I think it is reasonable
to not restart the VM. For any other error condition, I think it is
reasonable to not restart the VM.
I think that there is no single answer for all users and all applications.
In my case, I am running BHyve VM's as headless which
I access via the /dev/nmdm driver. If the VM reboots normally, I want it
to restart.
It seems almost any boot failure would be host side for example if there is
no SSH access (which if the instance is never logged into then it is likely
a host issue) then it is highly unlikely the VM is in bootable form (this
is after a manual reboot of it)... an other reason (just learned the
hardway) is the user uses a mismatch between backing file formats (my case
using raw images with ahci-hd)
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
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
___
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: Networking issues
Hi Sebastian, On Fri, Feb 7, 2014 at 12:03 PM, ick...@gmail.com wrote: Hello virtualization-lovers, I am very dedicated to FreeBSD since 7.2 and welcome the new bhyve hypervisor. :) So I set everything up, launched the guest and set up the network. The problem now is, I can reach the host IP, but not the default gateway. Did I forget to set something up? The system is a hosted root box. My current setup (i changed the IP's except the last octet): ---snip--- host: # ifconfig re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=82099RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE ether 30:85:a9:ed:01:22 inet 192.168.0.137 netmask 0xffe0 broadcast 192.168.0.159 inet6 fe80::3285:a9ff:feed:122%re0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active bridge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 02:0d:2a:df:6e:00 nd6 options=1PERFORMNUD id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 4 priority 128 path cost 200 member: re0 flags=143LEARNING,DISCOVER,AUTOEDGE,AUTOPTP ifmaxaddr 0 port 1 priority 128 path cost 2 tap0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:fe:79:0e:00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect status: active Opened by PID 16910 # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default5.9.157.129UGS 0 293321re0 192.168.0.128/27 link#1 U 0 30re0 192.168.0.137 link#1 UHS 00lo0 127.0.0.1 link#2 UH 0 1606lo0 ---snip--- ---snip--- guest: # ifconfig vtnet0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=80028VLAN_MTU,JUMBO_MTU,LINKSTATE ether 00:a0:98:18:c4:69 inet 192.168.0.154 netmask 0xffe0 broadcast 192.168.0.159 inet6 fe80::2a0:98ff:fe18:c469%vtnet0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet 10Gbase-T full-duplex status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default5.9.157.129UGS 0 418 vtnet0 192.168.0.128/27 link#1 U 0 24 vtnet0 192.168.0.154 link#1 UHS 00lo0 127.0.0.1 link#2 UH 0 24lo0 ---snip--- ping host - guest works # ping 192.168.0.154 PING 192.168.0.154 (192.168.0.154): 56 data bytes 64 bytes from 192.168.0.154: icmp_seq=0 ttl=64 time=0.083 ms 64 bytes from 192.168.0.154: icmp_seq=1 ttl=64 time=0.094 ms ping guest - host works # ping 192.168.0.137 PING 192.168.0.137 (192.168.0.137): 56 data bytes 64 bytes from 192.168.0.137: icmp_seq=0 ttl=64 time=0.398 ms 64 bytes from 192.168.0.137: icmp_seq=1 ttl=64 time=0.069 ms ping 173.194.70.102 (google.com) from guest - doesn't work... # ping 173.194.70.102 PING 173.194.70.102 (173.194.70.102): 56 data bytes --- 173.194.70.102 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss tcpdump listening on the host: # tcpdump -N -vv -i bridge0 tcpdump: WARNING: bridge0: no IPv4 address assigned tcpdump: listening on bridge0, link-type EN10MB (Ethernet), capture size 65535 bytes 19:58:19.139767 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has static tell 192.168.0.137, length 46 ---^ same on tap0 What's wrong with that setup? Did I forget to set a proper route? Or is it a MAC address issue? Can you ping the default router from your guest? Also, I was bit puzzled that the default router is 5.9.157.129 on a 192.168.0.128/27 subnet. Should I read it as 192.168.0.129 instead? best Neel Thanks in advance, Sebastian ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To
