I started seeing the following whines from emulated nvme on vmware
workstation some time ago, and it seems to happen almost exclusively
during the nightly periodic run:
Jul 3 03:01:47 titan kernel: nvme0: RECOVERY_START 48053105730250 vs
48051555254036
Jul 3 03:01:47 titan kernel: nvme0
On 06/03/2021 14:38, Fabien via freebsd-current wrote:
> Hello,
>
> A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI
> drive.
> At the end of the install it fails with the following error:
> https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote:
> Hello,
>
> A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI
> drive.
> At the end of the install it fails with the following error:
> https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote:
> Hello,
>
> A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI
> drive.
> At the end of the install it fails with the following error:
> https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote:
> Hello,
>
> A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI
> drive.
> At the end of the install it fails with the following error:
> https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k
Hello,
A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI drive.
At the end of the install it fails with the following error:
https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV
Is it planned to be fixed before release ?
Regards,
Fabien
15.02.2020, 20:44, "Toomas Soome" :
>> On 15. Feb 2020, at 22:19, Alexander V. Chernikov wrote:
>>
>> Hi folks,
>>
>> I upgraded vmware fusion to version 11 recently and noticed that my -amd64
>> VM stops booting immediately after printing
> On 15. Feb 2020, at 22:19, Alexander V. Chernikov wrote:
>
> Hi folks,
>
> I upgraded vmware fusion to version 11 recently and noticed that my -amd64 VM
> stops booting immediately after printing EFI framebuffer information.
>
> VM pops up a message stating that &
Hi folks,
I upgraded vmware fusion to version 11 recently and noticed that my -amd64 VM
stops booting immediately after printing EFI framebuffer information.
VM pops up a message stating that "The firmware encountered an unexpected
exception. The virtual machine cannot boot."
Furth
> On 14. Feb 2020, at 13:43, Yuri Pankov wrote:
>
> Hi Toomas,
>
> I was finally able to find the revision that has broken UEFI boot on VMware
> VMs, that is ESXi 6.7 and Workstation 15.x, for me at least -- VM simply
> powers off (sometimes with uninformative
Dag-Erling Smørgrav wrote:
> Yuri Pankov writes:
>> There's apparently a bug in VMware Workstation NAT implementation,
>> [...] The patch itself is attached.
>
> Could you please open a differential and add me as reviewer?
https://reviews.freebsd.org/D18636
And
In message <865zvkpphn@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > I know our code is full of workarounds and theirs probably too. The
> > question is should we? IMO no.
>
> Unfortunately, the world is imperfect and does not care about your
>
Yuri Pankov writes:
> There's apparently a bug in VMware Workstation NAT implementation,
> [...] The patch itself is attached.
Could you please open a differential and add me as reviewer?
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-c
Cy Schubert writes:
> Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then.
I don't speak for them, but I assure you that both their code and ours
are full of workarounds for bugs in third-party software and hardware,
and it is ridiculous to claim otherwise.
> No. We do like Red Hat
Cy Schubert writes:
> I know our code is full of workarounds and theirs probably too. The
> question is should we? IMO no.
Unfortunately, the world is imperfect and does not care about your
opinion. 90% of the hardware we run on deviates from the spec in some
way or another and requires
In message <86pntszlae@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then.
>
> I don't speak for them, but I assure you that both their code and ours
> are full of workarounds for bugs in
Cy Schubert writes:
> Add it to ssh_config or sshd_config if one must but have VMware fix
> their bugs. Putting workarounds in our O/S to work around a bug in some
> other vendor's virtualization is something I don't support.
It's something we do *all the time*. Otherwise we'd just
In message <861s681ypd@next.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rg
rav?= w
rites:
> Cy Schubert writes:
> > Add it to ssh_config or sshd_config if one must but have VMware fix
> > their bugs. Putting workarounds in our O/S to work around a bug in some
> > ot
In message <82004750-097a-47e5-9981-86b4b7a5f...@gmail.com>, Enji
Cooper writes
:
> > On Dec 22, 2018, at 1:03 PM, Cy Schubert =
> wrote:
>
> =E2=80=A6
>
> > Regarding the Red Hat bugzilla bug, looks like they're doing the right
> > thing by reaching out to
> On Dec 22, 2018, at 1:03 PM, Cy Schubert wrote:
…
> Regarding the Red Hat bugzilla bug, looks like they're doing the right
> thing by reaching out to VMware. This should be our position as well.
> Add it to ssh_config or sshd_config if one must but have VMware fix
> thei
rotected-headers="v1"
> From: Yuri Pankov
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>
> Subject: Re: workaround for VMw
protected-headers="v1"
>> From: Yuri Pankov
>> To: Cy Schubert
>> Cc: Mark Peek , Enji Cooper ,
>> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
>> , freebsd-current
>> Message-ID:
>> Subject: Re: workaround for VMware WS NAT bug trigg
> To: Cy Schubert
> Cc: Mark Peek , Enji Cooper ,
> Warner Losh , =?UTF-8?Q?Dag-Erling_Sm=c3=b8rgrav?=
> , freebsd-current
> Message-ID:
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
> changes
> References: <20181009.wbmk9h5t050.
i Cooper
> wro=
>>> te:
>>>> =20
>>>>>
>>>>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>>>>>>
>>>>>> Mark Peek wrote:
>>>>>>> Thanks for the cc:. I forwarded the original repor
>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>> >>>
>> >>> Mark Peek wrote:
>> >>>> Thanks for the cc:. I forwarded the original report on to an
interna=
>> l
>> >>>> VMware desktop product contact.
&
;> Thanks for the cc:. I forwarded the original report on to an internal
> >>>> VMware desktop product contact.
> >>>
> >>> Thank you.
> >>>
> >>>> What version of Workstation or Fusion is this occurring on? I saw
> >>>> Works
Mark Peek wrote:
> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote:
>
>>
>>> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>>>
>>> Mark Peek wrote:
>>>> Thanks for the cc:. I forwarded the original report on to an internal
>>>> V
On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper wrote:
>
> > On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
> >
> > Mark Peek wrote:
> >> Thanks for the cc:. I forwarded the original report on to an internal
> >> VMware desktop product contact.
> >
> &
> On Dec 21, 2018, at 17:48, Yuri Pankov wrote:
>
> Mark Peek wrote:
>> Thanks for the cc:. I forwarded the original report on to an internal
>> VMware desktop product contact.
>
> Thank you.
>
>> What version of Workstation or Fusion is this occurring o
Mark Peek wrote:
> Thanks for the cc:. I forwarded the original report on to an internal
> VMware desktop product contact.
Thank you.
> What version of Workstation or Fusion is this occurring on? I saw
> Workstation 14 mentioned but curious if it occurs on Workstation 15
> (la
Thanks for the cc:. I forwarded the original report on to an internal
VMware desktop product contact.
What version of Workstation or Fusion is this occurring on? I saw
Workstation 14 mentioned but curious if it occurs on Workstation 15
(latest).
Mark
On Fri, Dec 21, 2018 at 4:19 PM Warner Losh
I've been hit by this as well. At least two others on IRC have had the same
issue.
Warner
On Fri, Dec 21, 2018 at 5:10 PM Enji Cooper wrote:
>
> > On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
> >
> > Hi,
> >
> > There's apparently a bug in VMware Wor
> On Dec 21, 2018, at 3:55 PM, Yuri Pankov wrote:
>
> Hi,
>
> There's apparently a bug in VMware Workstation NAT implementation, made
> visible by the change to default values of IPQoS in OpenSSH 7.8p1,
> making all ssh connections from the guest behind the NAT t
Hi,
There's apparently a bug in VMware Workstation NAT implementation, made
visible by the change to default values of IPQoS in OpenSSH 7.8p1,
making all ssh connections from the guest behind the NAT to fail with
obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
Broken
On Sun, Dec 9, 2018 at 3:50 PM Chuck Tuffli wrote:
> On Sun, Dec 9, 2018 at 3:43 PM Yuri Pankov wrote:
>
>> Chuck Tuffli wrote:
>> > On Sat, Dec 8, 2018 at 12:28 PM Yuri Pankov > > <mailto:yur...@yuripv.net>> wrote:
>> >
>> > Hi,
>&
On Sun, Dec 9, 2018 at 3:43 PM Yuri Pankov wrote:
> Chuck Tuffli wrote:
> > On Sat, Dec 8, 2018 at 12:28 PM Yuri Pankov > <mailto:yur...@yuripv.net>> wrote:
> >
> > Hi,
> >
> > Running -HEAD in VMware Workstation 15.0.2 VM. Trying
On Sat, Dec 8, 2018 at 12:28 PM Yuri Pankov wrote:
> Hi,
>
> Running -HEAD in VMware Workstation 15.0.2 VM. Trying to use nda(4)
> instead of nvd(4) shows the following list of errors, and eventually
> panics:
>
> https://people.freebsd.org/~yuripv/nda1.png
> https://pe
Chuck Tuffli wrote:
> On Sat, Dec 8, 2018 at 12:28 PM Yuri Pankov <mailto:yur...@yuripv.net>> wrote:
>
> Hi,
>
> Running -HEAD in VMware Workstation 15.0.2 VM. Trying to use nda(4)
> instead of nvd(4) shows the following list of errors, and eventually
&
Hi,
Running -HEAD in VMware Workstation 15.0.2 VM. Trying to use nda(4)
instead of nvd(4) shows the following list of errors, and eventually panics:
https://people.freebsd.org/~yuripv/nda1.png
https://people.freebsd.org/~yuripv/nda2.png
nvd(4) works without issues in this VM. nda(4) works
Fri, 6 Apr 2018 08:39:27 -0700 (PDT)
> > > > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > >
> > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT)
> > > > > > "Rodney W. Grimes" <freebs
38:51 -0700 (PDT)
> > > > > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > > I'm trying to install FreeBS
...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > >
> > > > > > On Thu, 5 Apr 2018 22:38:51 -0700 (PDT)
> > > > > > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > > > >
> > > > >
Thu, 5 Apr 2018 22:38:51 -0700 (PDT)
> > > > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > >
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > > I'm trying to
I'm trying to install FreeBSD on :
VMWare ESXi, 6.0.0, 5050593
Guest OS: FreeBSD (64-bit)
Compatibility: ESXi 6.0 and later (VM version 11)
For 11.1R I'm getting the boot menu, then:
/boot/kernel/kernel text=014972f8
elf64_loadimage: read failed
can't load file: '/boot/kernel/kernel': input/out
Can you export the empty VM and make it available for download somewhere?
If you zero the disks with dd before exporting, it should compress very nicely.
I only have Fusion to test, though.
___
freebsd-current@freebsd.org mailing list
gt; >
> > > > > Hi,
> > > > >
> > > > >
> > > > > I'm trying to install FreeBSD on :
> > > > > VMWare ESXi, 6.0.0, 5050593
> > > > >
> > > > > Guest OS: FreeBSD (64-bit)
> > > >
t; Hi,
> > > >
> > > >
> > > > I'm trying to install FreeBSD on :
> > > > VMWare ESXi, 6.0.0, 5050593
> > > >
> > > > Guest OS: FreeBSD (64-bit)
> > > > Compatibility: ESXi 6.0 and later (VM version 11)
> > > &
> On Thu, 5 Apr 2018 22:38:51 -0700 (PDT)
> "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > Hi,
> > >
> > >
> > > I'm trying to install FreeBSD on :
> > > VMWare ESXi, 6.0.0, 5050593
> > >
On Thu, 5 Apr 2018 22:38:51 -0700 (PDT)
"Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > Hi,
> >
> >
> > I'm trying to install FreeBSD on :
> > VMWare ESXi, 6.0.0, 5050593
> >
> > Guest OS: FreeBSD (64
> Hi,
>
>
> I'm trying to install FreeBSD on :
> VMWare ESXi, 6.0.0, 5050593
>
> Guest OS: FreeBSD (64-bit)
> Compatibility: ESXi 6.0 and later (VM version 11)
>
> For 11.1R I'm getting the boot menu, then:
> /boot/kernel/kernel text=014972f8
> elf64_load
Hi,
I'm trying to install FreeBSD on :
VMWare ESXi, 6.0.0, 5050593
Guest OS: FreeBSD (64-bit)
Compatibility: ESXi 6.0 and later (VM version 11)
For 11.1R I'm getting the boot menu, then:
/boot/kernel/kernel text=014972f8
elf64_loadimage: read failed
can't load file: '/boot/kernel/kernel
VMware has been contributing to making FreeBSD a first class citizen for
their open source vmware tools.
As a continuing part of this contribution there's a new version of
open-vm-tools in the works. The INO64 work in FreeBSD HEAD broke
building open-vm-tools for HEAD/i386
- three crashes happened during
installation.
Running on VMware 12 Workstation. FreeBSD 10.3 RELEASE, Debian Linux,
Windows running there without any problems.
Is possible that filesystem is damaged/inconsistent after these crashes ?
data lost etc ?
Kar
On Thu, 19 May 2016 14:04:59 +0300
Andriy Gapon wrote:
> On 19/05/2016 13:50, Boris Samorodov wrote:
> > 19.05.16 09:28, K. Macy пишет:
> >> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
> >> did an IFC to r300176 and boot will hang right ater printing
19.05.16 16:43, Andriy Gapon пишет:
> On 19/05/2016 16:40, Boris Samorodov wrote:
>> 19.05.16 14:04, Andriy Gapon пишет:
>>> On 19/05/2016 13:50, Boris Samorodov wrote:
19.05.16 09:28, K. Macy пишет:
> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
> did an IFC to
On 19/05/2016 16:40, Boris Samorodov wrote:
> 19.05.16 14:04, Andriy Gapon пишет:
>> On 19/05/2016 13:50, Boris Samorodov wrote:
>>> 19.05.16 09:28, K. Macy пишет:
I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
did an IFC to r300176 and boot will hang right ater
19.05.16 14:04, Andriy Gapon пишет:
> On 19/05/2016 13:50, Boris Samorodov wrote:
>> 19.05.16 09:28, K. Macy пишет:
>>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>>> did an IFC to r300176 and boot will hang right ater printing out
>>> "setting hostid: ". ^T just shows sh
19.05.16 14:05, Konstantin Belousov пишет:
> On Thu, May 19, 2016 at 01:50:47PM +0300, Boris Samorodov wrote:
>> 19.05.16 09:28, K. Macy пишет:
>>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>>> did an IFC to r300176 and boot will hang right ater printing out
>>> "setting
On 19/05/2016 13:50, Boris Samorodov wrote:
> 19.05.16 09:28, K. Macy пишет:
>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>> did an IFC to r300176 and boot will hang right ater printing out
>> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
>> shell as
On Thu, May 19, 2016 at 01:50:47PM +0300, Boris Samorodov wrote:
> 19.05.16 09:28, K. Macy пишет:
> > I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
> > did an IFC to r300176 and boot will hang right ater printing out
> > "setting hostid: ". ^T just shows sh [piperd]. ddb just
19.05.16 09:28, K. Macy пишет:
> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
> did an IFC to r300176 and boot will hang right ater printing out
> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
> shell as hanging in piperead. Diffing between those two
I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
did an IFC to r300176 and boot will hang right ater printing out
"setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
shell as hanging in piperead. Diffing between those two revisions I
don't see any obvious offenders
. Sorry for that. Guess that's what
happens when I try to keep up with too many unrelated subprojects
at the same time.
No worries. Thanks for getting support for this in the tree. I look
forward to not rebooting production VMs after a VMDK resize.
And while on the subject of VMware+SCSI
On 0510T1522, Matthew Grooms wrote:
> On 11/28/2015 10:03 PM, Matthew Grooms wrote:
> > On 11/28/2015 6:10 PM, Matthew Grooms wrote:
> >> On 11/27/2015 7:44 PM, Matthew Grooms wrote:
> >>> I spent the day looking over the FreeBSD cam and scsi_da source code.
> >>> After sprinkling a bunch of
On 11/28/2015 10:03 PM, Matthew Grooms wrote:
On 11/28/2015 6:10 PM, Matthew Grooms wrote:
On 11/27/2015 7:44 PM, Matthew Grooms wrote:
I spent the day looking over the FreeBSD cam and scsi_da source code.
After sprinkling a bunch of printf's around to see what code paths
were being called,
On 11/27/2015 7:44 PM, Matthew Grooms wrote:
I spent the day looking over the FreeBSD cam and scsi_da source code.
After sprinkling a bunch of printf's around to see what code paths
were being called, It's obvious that Edward was correct in assuming
that ESXi doesn't return any 'Unit
On 11/28/2015 6:10 PM, Matthew Grooms wrote:
On 11/27/2015 7:44 PM, Matthew Grooms wrote:
I spent the day looking over the FreeBSD cam and scsi_da source code.
After sprinkling a bunch of printf's around to see what code paths
were being called, It's obvious that Edward was correct in assuming
at scbus1 target 0 lun 0 (cd0,pass0)
at scbus2 target 0 lun 0 (pass1,da0)
at scbus2 target 1 lun 0 (pass2,da1)
at scbus3 target 0 lun 0 (da2,pass3)
The da1 device is a virtual disk hanging off of a VMware virtual SAS
controller ...
[root@iscsi-i /home/mgrooms
of online UFS
filesystems via growfs. Unfortunately, it would appear that there are
still problems in this area, such as ...
a) cam/geom recognizing when a drive's size has increased
b) zpool recognizing when a gpt partition size has increased
For example, if I do an install of FreeBSD 10 on VMware
output. So it would appear
that even though cam is reporting the new capacity in the command line
output, the this info is not being forwarded to geom in this case.
Maybe the VMware virtual SAS device ( mpt0 ) isn't reporting some
special capability bit to cam which causes it to squelch the info
, it would appear that there are
still problems in this area, such as ...
a) cam/geom recognizing when a drive's size has increased
b) zpool recognizing when a gpt partition size has increased
For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see
the following ...
root@zpool-test
in this area, such as ...
a) cam/geom recognizing when a drive's size has increased
b) zpool recognizing when a gpt partition size has increased
For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see
the following ...
root@zpool-test:~ # gpart show
=> 34 16777149 da0
sends proper Unit
Attention after resizing. No idea why this doesn't happen with
VMWare. Reboot obviously clears things up.
[..]
Is open-vm-tools installed?
I ask because if I don't have it installed and the kernel modules
loaded, VMware doesn't notify the guest OS of disks being
added/removed
recognizing when a drive's size has increased
b) zpool recognizing when a gpt partition size has increased
For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see
the following ...
root@zpool-test:~ # gpart show
= 34 16777149 da0 GPT (8.0G)
34 1024
. No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.
[..]
Is open-vm-tools installed?
I ask because if I don't have it installed and the kernel modules loaded,
VMware doesn't notify the guest OS of disks being added/removed.
Also, what disk controller are you using
proper Unit
Attention
after resizing. No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.
[..]
Is open-vm-tools installed?
I ask because if I don't have it installed and the kernel modules
loaded, VMware doesn't notify the guest OS of disks being
added/removed
) zpool recognizing when a gpt partition size has increased
For example, if I do an install of FreeBSD 10 on VMware using ZFS, I see
the following ...
root@zpool-test:~ # gpart show
= 34 16777149 da0 GPT (8.0G)
34 10241 freebsd-boot (512K)
1058 41943042
- Original Message -
- Original Message -
Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime):
...
snip
The intr usage is higher than the other drivers you compared against
because if_vmx does the off-level processing in ithreads where as the
.
[1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/
Thanks a lot for your ongoing work!
I can confirm that with recent if_vmx.c from head and compiled for
9.2-RC3, setting mtu to 9000 works as expected :-)
I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
HEAD and was
able to change the MTU to 9000.
[1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/
Thanks a lot for your ongoing work!
I can confirm that with recent if_vmx.c from head and compiled for
9.2-RC3, setting mtu to 9000 works as expected :-)
I took a oldish
of 'it works', I'm interested performance vs
the emulated e1000, and (for those using it) the VMware tools vmxnet3
driver. Hopefully it is no worse :)
Hello Bryan,
thanks a lot for your hard work!
It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get
»vmx0: cannot
the emulated e1000, and (for those using it) the VMware tools vmxnet3
driver. Hopefully it is no worse :)
Hello Bryan,
thanks a lot for your hard work!
It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get
»vmx0: cannot populate Rx queue 0«, I have no problems using jumbo
frames
On 8/6/13 6:52 AM, Bryan Venteicher wrote:
- Original Message -
I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
VMware tools package from VMware. Everything has been running great for
years.
(we skipped vSphere 5.0). Why should I use this vmxnet driver instead
- Original Message -
it'd be nice if we could get vmware to just support the drivers in tree..
by which I mean, just submit patches.. why do they need to have it out
of tree?
I agree. But they are all unfriendly licensed. The FF had a discussion
to get them relicensed to something
that was fixed. But they've less helpful
in other regards, and have more or less said FreeBSD isn't high in their
priority because it isn't Linux.
Are you aiming at completely replacing VMware tools, or just the device
drivers?
I'd like as much as possible to work out of the box. vmxnet3 is as far as
my
. At $JOB, we got caught by the FreeBSD
specific issue of the busted timer that was fixed. But they've less helpful
in other regards, and have more or less said FreeBSD isn't high in their
priority because it isn't Linux.
Are you aiming at completely replacing VMware tools, or just the device
the emulated e1000, and (for those using it) the VMware tools vmxnet3
driver. Hopefully it is no worse :)
I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
VMware tools package from VMware. Everything has been running great for years.
(we skipped vSphere 5.0). Why should I use
- Original Message -
I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
VMware tools package from VMware. Everything has been running great for
years.
(we skipped vSphere 5.0). Why should I use this vmxnet driver instead of the
VMware tools driver
On Mon, Aug 05, 2013 at 05:52:01PM -0500, Bryan Venteicher wrote:
- Original Message -
I have ~100 FreeBSD 8/9 VMs in my vSphere 5.1 environment, all using the
VMware tools package from VMware. Everything has been running great for
years.
(we skipped vSphere 5.0). Why should I
]. Alternatively, the driver and a Makefile is
at [2]; this should compile at least as far back as 9.1. I can look at
8-STABLE if there is interest.
Obviously, besides reports of 'it works', I'm interested performance vs
the emulated e1000, and (for those using it) the VMware tools vmxnet3
driver
On Tue, Jul 30, 2013 at 5:55 PM, John Baldwin j...@freebsd.org wrote:
On Tuesday, July 30, 2013 5:25:06 am Alexander Yerenkow wrote:
Hello all.
I have panics in vmware with installed vmwaretools (they are guessed
culprit).
Seems that memory balooning (or using more memory in all vms than
:
Hello all.
I have panics in vmware with installed vmwaretools (they are guessed
culprit).
Seems that memory balooning (or using more memory in all vms than there
is
in host)
produces some kind of weird behavior in FreeBSD.
This vm aren't shutted down now, is there somethin I can do to help
On Fri, Aug 2, 2013 at 8:27 PM, Alexander Yerenkow yeren...@gmail.com wrote:
That was their official tools, which are came from ISO which mounted with
command install/upgrade client tools.
There is not much I can do then, unless they update their source-code.
Or do you have any pointer?
2013/8/2 Attilio Rao atti...@freebsd.org
On Fri, Aug 2, 2013 at 8:27 PM, Alexander Yerenkow yeren...@gmail.com
wrote:
That was their official tools, which are came from ISO which mounted with
command install/upgrade client tools.
There is not much I can do then, unless they update
Can I suggest?
We desperately need for vmware page at wiki.
I created stub, will fill it with known info to me, help and experience
appreciated!
https://wiki.freebsd.org/VmWare
P.S. Some time ago there was message in lists, about improved speed of
intel-emulated network card under vmware
On Tuesday, July 30, 2013 5:25:06 am Alexander Yerenkow wrote:
Hello all.
I have panics in vmware with installed vmwaretools (they are guessed
culprit).
Seems that memory balooning (or using more memory in all vms than there is
in host)
produces some kind of weird behavior in FreeBSD
Hello all.
I have panics in vmware with installed vmwaretools (they are guessed
culprit).
Seems that memory balooning (or using more memory in all vms than there is
in host)
produces some kind of weird behavior in FreeBSD.
This vm aren't shutted down now, is there somethin I can do to help
On Tuesday, July 30, 2013 5:25:06 am Alexander Yerenkow wrote:
Hello all.
I have panics in vmware with installed vmwaretools (they are guessed
culprit).
Seems that memory balooning (or using more memory in all vms than there is
in host)
produces some kind of weird behavior in FreeBSD
On May 23, 2013, at 23:20, Guy Helmer guy.hel...@gmail.com wrote:
I've tried using drivers xf86-video-vmware (vmware) and xf86-video-vesa
(vesa) for 10-current under VMware Fusion. Regardless, the X server fails
with the error:
[…]
(==) VESA(0): Backing store disabled
Fatal server
On Thu, 23 May 2013 16:20:35 -0500, Guy Helmer wrote:
I've tried using drivers xf86-video-vmware (vmware) and xf86-video-vesa
(vesa) for 10-current under VMware Fusion. Regardless, the X server
fails with the error:
[...]
Fatal server error:
AddScreen/ScreenInit failed for driver 0
1 - 100 of 343 matches
Mail list logo