emulated nvme on vmware workstation whines

[Yuri]

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: timeout with nothing complete,
resetting
Jul  3 03:01:47 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:01:47 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:01:47 titan kernel: nvme0: resetting controller
Jul  3 03:01:47 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:01:47 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:01:47 titan kernel: nvme0: READ sqid:10 cid:0 nsid:1
lba:8931648 len:8
Jul  3 03:01:47 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207341204759 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_START 48207722834338 vs
48207032791553
Jul  3 03:02:23 titan kernel: nvme0: timeout with nothing complete,
resetting
Jul  3 03:02:23 titan kernel: nvme0: Resetting controller due to a timeout.
Jul  3 03:02:23 titan kernel: nvme0: RECOVERY_WAITING
Jul  3 03:02:23 titan kernel: nvme0: resetting controller
Jul  3 03:02:23 titan kernel: nvme0: temperature threshold not supported
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o
Jul  3 03:02:23 titan kernel: nvme0: resubmitting queued i/o
Jul  3 03:02:23 titan kernel: nvme0: WRITE sqid:1 cid:0 nsid:1
lba:27806528 len:8
Jul  3 03:02:23 titan kernel: nvme0: aborting outstanding i/o

It does not seem to break anything, i.e. no errors from periodic, zpool
status and zpool scrub do not show any issues as well, so I'm just
wondering if there is some obvious reason for this.

I am staying current with, well, -CURRENT and VMware Workstation
versions (now at 16.2.3), and do not remember when exactly this started.
 There are no other VMs doing anything at that time, host system is
pretty idle as well.

Re: FreeBSD 13-RC1 PVSCSI install error with VMware

[Andriy Gapon]

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=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV
> 
> Is it planned to be fixed before release ?

Please see if this helps:
https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077859.html
Note that you don't have to recompile, kern.maxphys in loader.conf or at the
loader prompt should work as well.

But it would be ideal to fix the issue in the driver.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 13-RC1 PVSCSI install error with VMware

[Dennis Clarke via freebsd-current]

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=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV
> 
> Is it planned to be fixed before release ?

Sorry but it all works great here :

sedna_esxi# cat
/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar.vmx
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "10"
nvram = "deathstar.nvram"
pciBridge0.present = "TRUE"
svga.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
displayName = "deathstar"
extendedConfigFile = "deathstar.vmxf"
virtualHW.productCompatibility = "hosted"
floppy0.present = "FALSE"
numvcpus = "2"
memSize = "8192"
powerType.powerOff = "hard"
powerType.reset = "hard"
tools.upgrade.policy = "manual"
scsi0.virtualDev = "pvscsi"
scsi0.present = "TRUE"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "d_0.vmdk"
scsi0:0.present = "TRUE"
ide1:0.deviceType = "cdrom-image"
ide1:0.fileName =
"/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/iso_images/FreeBSD-13.0-RC1-amd64-disc1.iso"
ide1:0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "vm_net_01"
ethernet0.addressType = "generated"
ethernet0.present = "TRUE"
svga.autodetect = "TRUE"
guestOS = "other-64"
vcpu.hotadd = "TRUE"
mem.hotadd = "TRUE"
tools.syncTime = "FALSE"
uuid.bios = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea"
vc.uuid = "52 c3 0a e2 b1 48 4f 38-8f 18 69 01 ec 77 bf 07"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:1.fileName = "d_1.vmdk"
scsi0:1.present = "TRUE"
bios.forceSetupOnce = "FALSE"
sched.swap.derivedName =
"/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar-f1184228.vswp"
uuid.location = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea"
replay.supported = "FALSE"
replay.filename = ""
scsi0:0.redo = ""
scsi0:1.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "160"
ethernet0.pciSlotNumber = "32"
vmci0.pciSlotNumber = "33"
scsi0.sasWWID = "50 05 05 67 c5 ca b8 f0"
ethernet0.generatedAddress = "00:0c:29:26:1b:ea"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "-1138353174"
monitor.phys_bits_used = "40"
vmotion.checkpointFBSize = "16777216"
cleanShutdown = "FALSE"
softPowerOff = "FALSE"
sedna_esxi#

I hate being that guy that says "works for me"(tm) however ... it does.

-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 13-RC1 PVSCSI install error with VMware

[Dennis Clarke via freebsd-current]

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=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV
> 
> Is it planned to be fixed before release ?

I just took a look at :

Configuring disks to use VMware Paravirtual SCSI
(PVSCSI) controllers (1010398)

https://kb.vmware.com/s/article/1010398

Where it seems you are definately using ESXi and I also have ESXi here
to test with.  However it is unclear how you configured your disk(s) and
controllers.  Can you provide some details on the config and how you
arrived at this bug?


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 13-RC1 PVSCSI install error with VMware

[Dennis Clarke via freebsd-current]

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=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV
> 
> Is it planned to be fixed before release ?

Interesting error. Was this :

1) VMware Workstation of some flavour ?

2) ESXi or VMware vSphere server based ?

What are the specs of the virtual machine ? Just some basics here.
A little data please.


In the meanwhile I will fire up RC1 on both Xeon based hardware and on
VMware vSphere and VMware workstation just to see what happens.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD 13-RC1 PVSCSI install error with VMware

[Fabien via freebsd-current]

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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current does not boot on vmware fusion 11

[Alexander V . Chernikov]

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 EFI framebuffer information.
>>
>>  VM pops up a message stating that "The firmware encountered an unexpected 
>> exception. The virtual machine cannot boot."
>>
>>  Further digging revealed that the fusion upgrade bumped vmware virtual HW 
>> version to 16. Downgrading it to version 15 enabled VM to work again as 
>> expected.
>>
>>  Description of HWv16 include "UEFI Secure Boot" as one of the declared 
>> features, which looks like the potential candidate reason. The full feature 
>> list is available below.
>>  How can I debug this further?
>
> We do not do secure boot. However, there is known issue I am trying to fix. 
> You can try to run from ok prompt: ls and then boot.

Got it.
thank you for the prompt reply!
Any issue/review/code part/etc I can subscribe to get the notifications?

I switched the VM to version 16, jumped to the loader prompt, entered "ls", 
then "boot". The result is still the "The firmware encountered an unexpected 
exception" message.
Do I need to install the latest boot loader/do something else to workaround the 
issue?
I'm not blocked in any way with it, version 15 works just fine, just want to 
ensure this is the same problem.

Thank you!

>
> rgds,
> toomas
>
>>  Details:
>>  Host: macbook pro 2017, Intel core i7, Mojave 10.14.6
>>  VM: r357812, amd64.
>>  Vmware Fusion 11.5.1 (15018442)
>>
>>  Full VM output before the error:
>>
>>  Loading kernel...
>>  /boot/kernel/kernel text=0x1562084 data=0xe0 data=0x1b5158+0x449ea8 
>> syms=[0x8+0x 174e70+0x8+0x19408f] Loading configured modules...
>>  can't find I/boot/entropy'
>>  Start @ 0x80369000 ...
>>  EFI framebuffer information:
>>  adds, size 0xf000, 0x30
>>  dimensions 1024 x 768
>>  stride 1024
>>  masks 0x00ff, 0xff00, 0x00ff, 0xff00
>>  -
>>
>>  HWv16 description from https://blogs.vmware.com/teamfusion :
>>
>>  Included in HWv16 are:
>>  Improved Virtual NVMe Device Performance
>>  Important Security Fixes (Spectre, Meltdown and L1TF)
>>  Virtual Trusted Platform Module
>>  UEFI Secure Boot
>>  IOMMU
>>  VBS Support (guest only)
>>
>>  /Alexander
>>
>>  ___
>>  freebsd-current@freebsd.org mailing list
>>  https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>  To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: current does not boot on vmware fusion 11

[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 EFI framebuffer information.
> 
> VM pops up a message stating that "The firmware encountered an unexpected 
> exception. The virtual machine cannot boot."
> 
> Further digging revealed that the fusion upgrade bumped vmware virtual HW 
> version to 16. Downgrading it to version 15 enabled VM to work again as 
> expected.
> 
> Description of HWv16 include "UEFI Secure Boot" as one of the declared 
> features, which looks like the potential candidate reason. The full feature 
> list is available below.
> How can I debug this further?
> 

We do not do secure boot. However, there is known issue I am trying to fix. You 
can try to run from ok prompt: ls and then boot. 

rgds,
toomas


> 
> Details:
> Host: macbook pro 2017, Intel core i7, Mojave 10.14.6
> VM: r357812, amd64.
> Vmware Fusion 11.5.1 (15018442)
> 
> Full VM output before the error:
> 
> Loading kernel... 
> /boot/kernel/kernel text=0x1562084 data=0xe0 data=0x1b5158+0x449ea8 
> syms=[0x8+0x 174e70+0x8+0x19408f] Loading configured modules... 
> can't find I/boot/entropy'
> Start @ 0x80369000 ...
> EFI framebuffer information:
> adds, size 0xf000, 0x30
> dimensions 1024 x 768
> stride 1024
> masks 0x00ff, 0xff00, 0x00ff, 0xff00
> -
> 
> 
> HWv16 description from https://blogs.vmware.com/teamfusion :
> 
> Included in HWv16 are:
> Improved Virtual NVMe Device Performance
> Important Security Fixes (Spectre, Meltdown and L1TF)
> Virtual Trusted Platform Module
> UEFI Secure Boot
> IOMMU
> VBS Support (guest only)
> 
> 
> 
> /Alexander
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

current does not boot on vmware fusion 11

[Alexander V . Chernikov]

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."

Further digging revealed that the fusion upgrade bumped vmware virtual HW 
version to 16. Downgrading it to version 15 enabled VM to work again as 
expected.

Description of HWv16 include "UEFI Secure Boot" as one of the declared 
features, which looks like the potential candidate reason. The full feature 
list is available below.
How can I debug this further?


Details:
Host: macbook pro 2017, Intel core i7, Mojave 10.14.6
VM: r357812, amd64.
Vmware Fusion 11.5.1 (15018442)

Full VM output before the error:

Loading kernel... 
/boot/kernel/kernel text=0x1562084 data=0xe0 data=0x1b5158+0x449ea8 
syms=[0x8+0x 174e70+0x8+0x19408f] Loading configured modules... 
can't find I/boot/entropy'
Start @ 0x80369000 ...
EFI framebuffer information:
adds, size 0xf000, 0x30
dimensions 1024 x 768
stride 1024
masks 0x00ff, 0xff00, 0x00ff, 0xff00
-


HWv16 description from https://blogs.vmware.com/teamfusion :

Included in HWv16 are:
Improved Virtual NVMe Device Performance
Important Security Fixes (Spectre, Meltdown and L1TF)
Virtual Trusted Platform Module
UEFI Secure Boot
IOMMU
VBS Support (guest only)



/Alexander

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r351900 broke UEFI boot on VMware VMs

[Toomas Soome]

> 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 message about runtime exception) 
> after loader messages and before displaying any kernel messages.
> 
> commit 9b4871ee590632c8f983fbc82fea6a95a01e8c76 (HEAD)
> Author: tsoome 
> Date:   Thu Sep 5 22:15:50 2019 +
> 
>loader: use teken teminal emulator for x86 and uefi
> 
>Replace mini cons25 emulator with teken, this does enable us proper console
>terminal for loader and will make it possible to implement different
>back end callbacks to draw to screen.
> 
>At this time we still only "draw" in text mode.
> 
> Notes:
>svn path=/head/; revision=351900
> 
> Done by bisecting, building full ISO for every step, so it's likely correct.  
> Any ideas?


I am currently working with that code, so hopefully will be able to find the 
root cause soon enough. I am able to replicate the issue on fusion, for time 
being, I have found that if you esc out from menu and enter ls command, the 
crash wont happen:) 

sorry,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

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 there's already a PR for this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234426



signature.asc
Description: OpenPGP digital signature

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

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
> opinion.

Correct. I know that too well.

>  90% of the hardware we run on deviates from the spec in some
> way or another and requires workarounds in the kernel.  We even have a
> whole system of quirks for disks and USB devices.  Libfetch contains
> workarounds for buggy HTTP servers.  OpenSSH has hundreds of lines of
> code devoted to identifying the server and selecting workarounds to
> apply.  Without those workarounds, FreeBSD would not be a viable piece
> of software.  Wishing they weren't needed is a waste of time and energy.

Well, the patch isn't a hackish as some workounds. This probably 
doesn't warrant a MK_option however since it changes the default, a 
mention in the man page should be made.

I'm still of the opinion that a management solution would be better, 
which I'm sure RH is taking.

I've been in this business long enough to know that it's a miracle that 
any of this stuff works. Much of it is held together with bubble gum 
and string.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Dag-Erling Smørgrav]

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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Dag-Erling Smørgrav]

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 does. Advise the customer to use a workaround 
> until the other vendor fixes their code.

With respect, that's not your decision.  It's mine.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Dag-Erling Smørgrav]

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 workarounds in the kernel.  We even have a
whole system of quirks for disks and USB devices.  Libfetch contains
workarounds for buggy HTTP servers.  OpenSSH has hundreds of lines of
code devoted to identifying the server and selecting workarounds to
apply.  Without those workarounds, FreeBSD would not be a viable piece
of software.  Wishing they weren't needed is a waste of time and energy.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

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 third-party software and hardware,
> and it is ridiculous to claim otherwise.

I know our code is full of workarounds and theirs probably too. The 
question is should we? IMO no. It's yet another thing that diverges 
from baseline and that adds support costs (well, ok we're not a for 
profit business but you get the idea). Sure, you may be the person to 
support ssh here but divergence from baseline is usually not a good 
thing. When I was developer as a living management would rule against 
this kind of thing. Their rationale at the time was, "what if you're 
away?" At the time I'd curse at them but thinking about it years later, 
they did have a point.

>
> > No. We do like Red Hat does. Advise the customer to use a workaround 
> > until the other vendor fixes their code.
>
> With respect, that's not your decision.  It's mine.

With respect, I disagree with your decision then.

Please don't make that decision because your going to show me though.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Dag-Erling Smørgrav]

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 be a toy OS
that hobbyists played with in the weekends on an old spare machine they
keep in a basement closet.

> If we must 
> add the #ifdefs to our ssh, then add an UPDATING entry to say that to 
> enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it 
> in src.conf.

Then it's useless.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

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 
> > other vendor's virtualization is something I don't support.
>
> It's something we do *all the time*.  Otherwise we'd just be a toy OS
> that hobbyists played with in the weekends on an old spare machine they
> keep in a basement closet.

Hmmm. I guess Red Hat Enterprise Linux must be a toy OS then.

>
> > If we must 
> > add the #ifdefs to our ssh, then add an UPDATING entry to say that to 
> > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it 
> > in src.conf.
>
> Then it's useless.

No. We do like Red Hat does. Advise the customer to use a workaround 
until the other vendor fixes their code.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

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 VMware. This should be our position as well.
> > 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. If we must
> > add the #ifdefs to our ssh, then add an UPDATING entry to say that to
> > enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable =
> it
> > in src.conf.
>
> This is the reason why I CCed mp@ :).. Mark works for VMware (I worked =
> with him a bit when I was at Isilon).
>
> =E2=80=A6
>
> > We, FreeBSD, should try to open a ticket or reach out to VMware to add
> > a +1 to the issue that RH has already opened. This is the right thing
> > to do. In this case we should consider ourselves an O/S vendor too,
> > which BTW we are.
>
> Yes, but unless there=E2=80=99s a champion internal to the project =
> driving this, it=E2=80=99s up to individual users to drive the bug =
> report/fix. If, however, there were regular regression tests run with =
> VMware (and this can be done with pyvmomi/paramiko, etc), then we the =
> project could provide this guarantee to VMware and vice versa if VMware =
> invested the time in making this so--which I thought they did with =
> 10.x=E2=80=A6 but if they don=E2=80=99t have an easy way to verify =
> changes, there=E2=80=99s a bit of a chicken and egg problem.

I'm suggesting we do.

Regression tests might require that FreeBSD have a VMware cluster of 
one or preferably two machines somewhere. That is if VMware is willing 
to "help" out. The reason I suggest a cluster of two is vmotion can 
negatively affect some applications (Oracle RAC comes to mind). It 
would be interesting to find out how FreeBSD and apps running on 
FreeBSD react to being vmotioned from one ESXi host to another.

Testing vCPU and vRAM hot add are other items that should be in our 
test suite.

How well would FreeBSD work with vNUMA?

>
> > BTW the 2018-11-08 entry in the RH bug talks about adding the
> > workaround to sshd_config.
>
> =E2=80=A6 which is what I did instead of making the code change.

Does this suggest that sshd on servers running under VMware are also 
affected, i.e. ssh session from a computer not running on VMware such 
as from real hardware or a from PuTTY session o a PC to sshd on a VM?

>
> Thanks so very much for the patch and (more importantly) for the =
> discussion/solution Yuri!! I really appreciate your unblocking me.

Yes, thank you Yuri for pointing out the problem and providing a 
solution.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Enji Cooper]

> 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
> 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. If we must
> add the #ifdefs to our ssh, then add an UPDATING entry to say that to
> enable it put VMWARE_GUEST_WORKAROUND or however we choose to enable it
> in src.conf.

This is the reason why I CCed mp@ :).. Mark works for VMware (I worked with him 
a bit when I was at Isilon).

…

> We, FreeBSD, should try to open a ticket or reach out to VMware to add
> a +1 to the issue that RH has already opened. This is the right thing
> to do. In this case we should consider ourselves an O/S vendor too,
> which BTW we are.

Yes, but unless there’s a champion internal to the project driving this, it’s 
up to individual users to drive the bug report/fix. If, however, there were 
regular regression tests run with VMware (and this can be done with 
pyvmomi/paramiko, etc), then we the project could provide this guarantee to 
VMware and vice versa if VMware invested the time in making this so--which I 
thought they did with 10.x… but if they don’t have an easy way to verify 
changes, there’s a bit of a chicken and egg problem.

> BTW the 2018-11-08 entry in the RH bug talks about adding the
> workaround to sshd_config.

… which is what I did instead of making the code change.

Thanks so very much for the patch and (more importantly) for the 
discussion/solution Yuri!! I really appreciate your unblocking me.
Cheers,
-Enji


signature.asc
Description: Message signed with OpenPGP

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

In message <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>, Yuri 
Pankov write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --e7sW91Qf9WxzTaujtGEdAimN5k2EtpJ6Q
> Content-Type: multipart/mixed; boundary="3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm";
>  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: <0503b382-d886-39a4-d265-b43d8adc1...@yuripv.net>
> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1
>  changes
> References: <20181027.wbmkrgwj050...@slippy.cwsent.com>
> In-Reply-To: <20181027.wbmkrgwj050...@slippy.cwsent.com>
>
> --3a9zlXDI7Z2P48EdQkgwMdVOMQOEfR5Wm
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Cy Schubert wrote:
> > In message , Yuri=20
> > Pankov write
> > s:
> >> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> >> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
> >> Content-Type: multipart/mixed; boundary=3D"c7yUHUJpZYpJqOrOWLAb4sE3Rmh=
> 2alrdi";
> >>  protected-headers=3D"v1"
> >> From: Yuri Pankov 
> >> To: Cy Schubert 
> >> Cc: Mark Peek , Enji Cooper ,
> >>  Warner Losh , =3D?UTF-8?Q?Dag-Erling_Sm=3Dc3=3Db8rgra=
> v?=3D
> >>  , freebsd-current 
> >> Message-ID: 
> >> Subject: Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8=
> p1
> >>  changes
> >> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> >> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> >>
> >> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
> >> Content-Type: text/plain; charset=3Dutf-8
> >> Content-Language: en-US
> >> Content-Transfer-Encoding: quoted-printable
> >>
> >> Cy Schubert wrote:
> >>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=3D=
> 20
> >>> Pankov write
> >>> s:
> >>>> Yuri Pankov  wrote:
> >>>>> In-Reply-To:  ai=3D
> >>
> >>> l.gmail.
> >>>>> com>
> >>>>> Mark Peek wrote:
> >>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper  >
> >>>  wro=3D3D
> >>>>> te:
> >>>>>> =3D3D20
> >>>>>>>
> >>>>>>>> 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=3D=
> 20
> >>> interna=3D3D
> >>>>> l
> >>>>>>>>> VMware desktop product contact.
> >>>>>>>>
> >>>>>>>> Thank you.
> >>>>>>>>
> >>>>>>>>> What version of Workstation or Fusion is this occurring on? I=3D=
> 20
> >>> saw
> >>>>>>>>> Workstation 14 mentioned but curious if it occurs on=3D20
> >>> Workstation 15
> >>>>>>>>> (latest).
> >>>>>>>>
> >>>>>>>> Running the latest available for download: 15.0.2 build-10952284=
> =2E
> >>>>>>>
> >>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=3D=
> 20
> >>> wasn=3D3DE2=3D3D
> >>>>> =3D3D80=3D3D99t
> >>>>>>> affecting me on 10.x. I didn=3D3DE2=3D3D80=3D3D99t install 11.0.0=
> , so I=3D20
> >>> don=3D3DE2=3D3D80=3D3D99=3D3D
> >>>>> t know if it
> >>>>>>> affects that version...
> >>>>>>>
> >>>>>>> Thanks so much!
> >>>>>>>
> >>>>>>> -Enji
> >>>>>> =3D3D20
> >>>>>> =3D3D20
> >>>>>> BTW, there appears to be a workaround here using -o=3D20
> >>> 'IPQoS=3D3D3Dthroughput=3D3D
> >>>>> '
> >>>>>> (untested by me). I've seen the issue forwarded internally but no=3D=
> 20
> >>> furth=3D3D
> >>>>> er
> >>>>>> discussions yet.
> >>>>>> =3D3D20
> >>>>>> https://communities.vmware.com/thread/590825
> >>>>
> >>>> Yes, tha

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

Cy Schubert wrote:
> In message , Yuri 
> Pankov write
> s:
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
>> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi";
>>  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 triggered by OpenSSH 7.8p1
>>  changes
>> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>>
>> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
>> Content-Type: text/plain; charset=utf-8
>> Content-Language: en-US
>> Content-Transfer-Encoding: quoted-printable
>>
>> Cy Schubert wrote:
>>> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20
>>> Pankov write
>>> s:
>>>> Yuri Pankov  wrote:
>>>>> In-Reply-To: >
>>> l.gmail.
>>>>> com>
>>>>> Mark Peek wrote:
>>>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper 
>>>  wro=3D
>>>>> te:
>>>>>> =3D20
>>>>>>>
>>>>>>>> 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=20
>>> interna=3D
>>>>> l
>>>>>>>>> VMware desktop product contact.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>>> What version of Workstation or Fusion is this occurring on? I=20
>>> saw
>>>>>>>>> Workstation 14 mentioned but curious if it occurs on=20
>>> Workstation 15
>>>>>>>>> (latest).
>>>>>>>>
>>>>>>>> Running the latest available for download: 15.0.2 build-10952284.
>>>>>>>
>>>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20
>>> wasn=3DE2=3D
>>>>> =3D80=3D99t
>>>>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20
>>> don=3DE2=3D80=3D99=3D
>>>>> t know if it
>>>>>>> affects that version...
>>>>>>>
>>>>>>> Thanks so much!
>>>>>>>
>>>>>>> -Enji
>>>>>> =3D20
>>>>>> =3D20
>>>>>> BTW, there appears to be a workaround here using -o=20
>>> 'IPQoS=3D3Dthroughput=3D
>>>>> '
>>>>>> (untested by me). I've seen the issue forwarded internally but no=20
>>> furth=3D
>>>>> er
>>>>>> discussions yet.
>>>>>> =3D20
>>>>>> https://communities.vmware.com/thread/590825
>>>>
>>>> Yes, that's exactly what the patch attached to original message does i=
>> f
>>>> we are running as a VMware guest.  The workaround is known and it work=
>> s,
>>>> but it's not immediately clear and I just wanted it to be the default
>>>> for the time being.
>>> =20
>>> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20
>>> intended?
>>
>> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
>> be ripped out easily when no longer needed, and yes, it's enabled
>> unconditionally for now.  And the check itself is if 'kern.vm_guest'
>> reports 'vmware'.
> 
> It doesn't look that conditional to me.

Indeed, and that's what I said exactly :-)  The added code is enabled
unconditionally, and the added code also has a check for vmware guest.
The ifdefs are there only to show that this is local addition, nothing else.

I'm not saying it needs to be done this way, this is just something I
did quickly after installing yet another VM and forgetting to modify my
~/.ssh/config to include the workaround.



signature.asc
Description: OpenPGP digital signature

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

In message , Yuri 
Pankov write
s:
> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --NAG3HGfiwhsHyGq3aNdsIv1NzTEMODbUH
> Content-Type: multipart/mixed; boundary="c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi";
>  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 triggered by OpenSSH 7.8p1
>  changes
> References: <20181009.wbmk9h5t050...@slippy.cwsent.com>
> In-Reply-To: <20181009.wbmk9h5t050...@slippy.cwsent.com>
>
> --c7yUHUJpZYpJqOrOWLAb4sE3Rmh2alrdi
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> Cy Schubert wrote:
> > In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri=20
> > Pankov write
> > s:
> >> Yuri Pankov  wrote:
> >>> In-Reply-To: 
> > l.gmail.
> >>> com>
> >>> Mark Peek wrote:
> >>>> On Fri, Dec 21, 2018 at 9:30 PM Enji Cooper 
> >  wro=3D
> >>> te:
> >>>> =3D20
> >>>>>
> >>>>>> 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=20
> > interna=3D
> >>> l
> >>>>>>> VMware desktop product contact.
> >>>>>>
> >>>>>> Thank you.
> >>>>>>
> >>>>>>> What version of Workstation or Fusion is this occurring on? I=20
> > saw
> >>>>>>> Workstation 14 mentioned but curious if it occurs on=20
> > Workstation 15
> >>>>>>> (latest).
> >>>>>>
> >>>>>> Running the latest available for download: 15.0.2 build-10952284.
> >>>>>
> >>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it=20
> > wasn=3DE2=3D
> >>> =3D80=3D99t
> >>>>> affecting me on 10.x. I didn=3DE2=3D80=3D99t install 11.0.0, so I=20
> > don=3DE2=3D80=3D99=3D
> >>> t know if it
> >>>>> affects that version...
> >>>>>
> >>>>> Thanks so much!
> >>>>>
> >>>>> -Enji
> >>>> =3D20
> >>>> =3D20
> >>>> BTW, there appears to be a workaround here using -o=20
> > 'IPQoS=3D3Dthroughput=3D
> >>> '
> >>>> (untested by me). I've seen the issue forwarded internally but no=20
> > furth=3D
> >>> er
> >>>> discussions yet.
> >>>> =3D20
> >>>> https://communities.vmware.com/thread/590825
> >>
> >> Yes, that's exactly what the patch attached to original message does i=
> f
> >> we are running as a VMware guest.  The workaround is known and it work=
> s,
> >> but it's not immediately clear and I just wanted it to be the default
> >> for the time being.
> >=20
> > The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this=20
> > intended?
>
> It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
> be ripped out easily when no longer needed, and yes, it's enabled
> unconditionally for now.  And the check itself is if 'kern.vm_guest'
> reports 'vmware'.

It doesn't look that conditional to me.

diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+=  crypto
 CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
 .endif
 
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
 .include 
 
 .PATH: ${SSHDIR}


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

Cy Schubert wrote:
> In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri 
> Pankov write
> s:
>> Yuri Pankov  wrote:
>>> In-Reply-To:  l.gmail.
>>> com>
>>> Mark Peek wrote:
>>>> On Fri, Dec 21, 2018 at 9:30 PM Enji 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 report on to an 
> interna=
>>> l
>>>>>>> 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
>>>>>>> (latest).
>>>>>>
>>>>>> Running the latest available for download: 15.0.2 build-10952284.
>>>>>
>>>>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it 
> wasn=E2=
>>> =80=99t
>>>>> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I 
> don=E2=80=99=
>>> t know if it
>>>>> affects that version...
>>>>>
>>>>> Thanks so much!
>>>>>
>>>>> -Enji
>>>> =20
>>>> =20
>>>> BTW, there appears to be a workaround here using -o 
> 'IPQoS=3Dthroughput=
>>> '
>>>> (untested by me). I've seen the issue forwarded internally but no 
> furth=
>>> er
>>>> discussions yet.
>>>> =20
>>>> https://communities.vmware.com/thread/590825
>>
>> Yes, that's exactly what the patch attached to original message does if
>> we are running as a VMware guest.  The workaround is known and it works,
>> but it's not immediately clear and I just wanted it to be the default
>> for the time being.
> 
> The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this 
> intended?

It's the added code that is ifdef'ed VMWARE_GUEST_WORKAROUND, so it can
be ripped out easily when no longer needed, and yes, it's enabled
unconditionally for now.  And the check itself is if 'kern.vm_guest'
reports 'vmware'.

> Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and 
> Windows) running on VMware clusters with NSX network (with plans to 
> totally virtualize the network), we've noticed other network 
> quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris 
> <--> Linux. I'm not surprised that this regression also exists.
> 
> 




signature.asc
Description: OpenPGP digital signature

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Cy Schubert]

In message <913730b6-c6f0-60b8-a589-e89e872b7...@yuripv.net>, Yuri 
Pankov write
s:
> Yuri Pankov  wrote:
>> In-Reply-To: > com>
>> Mark Peek wrote:
>> > On Fri, Dec 21, 2018 at 9:30 PM Enji 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 report on to an 
interna=
>> l
>> >>>> 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
>> >>>> (latest).
>> >>>
>> >>> Running the latest available for download: 15.0.2 build-10952284.
>> >>
>> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it 
wasn=E2=
>> =80=99t
>> >> affecting me on 10.x. I didn=E2=80=99t install 11.0.0, so I 
don=E2=80=99=
>> t know if it
>> >> affects that version...
>> >>
>> >> Thanks so much!
>> >>
>> >> -Enji
>> >=20
>> >=20
>> > BTW, there appears to be a workaround here using -o 
'IPQoS=3Dthroughput=
>> '
>> > (untested by me). I've seen the issue forwarded internally but no 
furth=
>> er
>> > discussions yet.
>> >=20
>> > https://communities.vmware.com/thread/590825
>
> Yes, that's exactly what the patch attached to original message does if
> we are running as a VMware guest.  The workaround is known and it works,
> but it's not immediately clear and I just wanted it to be the default
> for the time being.

The patch assumes VMWARE_GUEST_WORKAROUND unconditionally. Is this 
intended?

Juxtaposed to this, at $JOB where our VMware guests (mostly Linux and 
Windows) running on VMware clusters with NSX network (with plans to 
totally virtualize the network), we've noticed other network 
quirkiness, most notably with NFS between unlike O/S's, i.e. Solaris 
<--> Linux. I'm not surprised that this regression also exists.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Warner Losh]

On Sat, Dec 22, 2018, 11:03 AM Yuri Pankov  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
> >>>> 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
> >>>> (latest).
> >>>
> >>> Running the latest available for download: 15.0.2 build-10952284.
> >>
> >> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t
> >> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it
> >> affects that version...
> >>
> >> Thanks so much!
> >>
> >> -Enji
> >
> >
> > BTW, there appears to be a workaround here using -o 'IPQoS=throughput'
> > (untested by me). I've seen the issue forwarded internally but no further
> > discussions yet.
> >
> > https://communities.vmware.com/thread/590825
>
> Yes, that's exactly what the patch attached to original message does if
> we are running as a VMware guest.  The workaround is known and it works,
> but it's not immediately clear and I just wanted it to be the default
> for the time being.
>

Fixes my world...

Warner

>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

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
>>>> 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
>>>> (latest).
>>>
>>> Running the latest available for download: 15.0.2 build-10952284.
>>
>> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t
>> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it
>> affects that version...
>>
>> Thanks so much!
>>
>> -Enji
> 
> 
> BTW, there appears to be a workaround here using -o 'IPQoS=throughput'
> (untested by me). I've seen the issue forwarded internally but no further
> discussions yet.
> 
> https://communities.vmware.com/thread/590825

Yes, that's exactly what the patch attached to original message does if
we are running as a VMware guest.  The workaround is known and it works,
but it's not immediately clear and I just wanted it to be the default
for the time being.



signature.asc
Description: OpenPGP digital signature

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Mark Peek]

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.
> >
> > 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
> >> (latest).
> >
> > Running the latest available for download: 15.0.2 build-10952284.
>
> This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t
> affecting me on 10.x. I didn’t install 11.0.0, so I don’t know if it
> affects that version...
>
> Thanks so much!
>
> -Enji


BTW, there appears to be a workaround here using -o 'IPQoS=throughput'
(untested by me). I've seen the issue forwarded internally but no further
discussions yet.

https://communities.vmware.com/thread/590825

Mark
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Enji Cooper]

> 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 on? I saw
>> Workstation 14 mentioned but curious if it occurs on Workstation 15
>> (latest).
> 
> Running the latest available for download: 15.0.2 build-10952284.

This is affecting me on VMware Fusion 11.0.1-11.0.2. I know it wasn’t affecting 
me on 10.x. I didn’t install 11.0.0, so I don’t know if it affects that 
version...

Thanks so much!

-Enji
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

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
> (latest).

Running the latest available for download: 15.0.2 build-10952284.

> On Fri, Dec 21, 2018 at 4:19 PM Warner Losh  wrote:
> 
>> 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 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 pipe".
>>>>
>>>> I wonder if we could integrate the attached patch (or some smarter
>>>> version of it) for the time being as the bug affects several major WS
>>>> releases, and it's not immediately clear where the problem is.
>>>>
>>>> The change itself:
>>>>
>>>>
>>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
>>>>
>>>> The bug reports (some of them):
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1624437
>>>> https://communities.vmware.com/message/2803219#2803219
>>>>
>>>> The patch itself is attached.
>>>> 
>>>
>>> Cool… yeah… I’ve been running into this issue for a while with
>>> VMware Fusion 11.0.1.
>>> I CCed mp@ for visibility.
>>> Thanks!
>>> -Enji
>>>
>>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 




signature.asc
Description: OpenPGP digital signature

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Mark Peek]

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  wrote:

> 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 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 pipe".
>> >
>> > I wonder if we could integrate the attached patch (or some smarter
>> > version of it) for the time being as the bug affects several major WS
>> > releases, and it's not immediately clear where the problem is.
>> >
>> > The change itself:
>> >
>> >
>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
>> >
>> > The bug reports (some of them):
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1624437
>> > https://communities.vmware.com/message/2803219#2803219
>> >
>> > The patch itself is attached.
>> > 
>>
>> Cool… yeah… I’ve been running into this issue for a while with
>> VMware Fusion 11.0.1.
>> I CCed mp@ for visibility.
>> Thanks!
>> -Enji
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[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 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 pipe".
> >
> > I wonder if we could integrate the attached patch (or some smarter
> > version of it) for the time being as the bug affects several major WS
> > releases, and it's not immediately clear where the problem is.
> >
> > The change itself:
> >
> >
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
> >
> > The bug reports (some of them):
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1624437
> > https://communities.vmware.com/message/2803219#2803219
> >
> > The patch itself is attached.
> > 
>
> Cool… yeah… I’ve been running into this issue for a while with
> VMware Fusion 11.0.1.
> I CCed mp@ for visibility.
> Thanks!
> -Enji
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Enji Cooper]

> 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 to fail with
> obscure "Fssh_packet_write_wait: Connection to 192.168.1.53 port 22:
> Broken pipe".
> 
> I wonder if we could integrate the attached patch (or some smarter
> version of it) for the time being as the bug affects several major WS
> releases, and it's not immediately clear where the problem is.
> 
> The change itself:
> 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284
> 
> The bug reports (some of them):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1624437
> https://communities.vmware.com/message/2803219#2803219
> 
> The patch itself is attached.
> 

Cool… yeah… I’ve been running into this issue for a while with VMware 
Fusion 11.0.1.
I CCed mp@ for visibility.
Thanks!
-Enji


signature.asc
Description: Message signed with OpenPGP

workaround for VMware WS NAT bug triggered by OpenSSH 7.8p1 changes

[Yuri Pankov]

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 pipe".

I wonder if we could integrate the attached patch (or some smarter
version of it) for the time being as the bug affects several major WS
releases, and it's not immediately clear where the problem is.

The change itself:

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/readconf.c#rev1.284

The bug reports (some of them):

https://bugzilla.redhat.com/show_bug.cgi?id=1624437
https://communities.vmware.com/message/2803219#2803219

The patch itself is attached.
diff --git a/crypto/openssh/readconf.c b/crypto/openssh/readconf.c
index f97a6ac72a95..9ed6902a0f46 100644
--- a/crypto/openssh/readconf.c
+++ b/crypto/openssh/readconf.c
@@ -16,6 +16,9 @@
 __RCSID("$FreeBSD$");
 
 #include 
+#ifdef VMWARE_GUEST_WORKAROUND
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -1954,6 +1957,15 @@ fill_default_options(Options * options)
 {
char *all_cipher, *all_mac, *all_kex, *all_key;
int r;
+#ifdef VMWARE_GUEST_WORKAROUND
+   char scval[7];  /* "vmware\0" */
+   size_t scsiz = sizeof(scval);
+   int vmwguest = 0;
+
+   if (sysctlbyname("kern.vm_guest", scval, , NULL, 0) == 0 &&
+   strcmp(scval, "vmware") == 0)
+   vmwguest = 1;
+#endif
 
if (options->forward_agent == -1)
options->forward_agent = 0;
@@ -2088,8 +2100,18 @@ fill_default_options(Options * options)
if (options->visual_host_key == -1)
options->visual_host_key = 0;
if (options->ip_qos_interactive == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+   if (vmwguest)
+   options->ip_qos_interactive = IPTOS_LOWDELAY;
+   else
+#endif
options->ip_qos_interactive = IPTOS_DSCP_AF21;
if (options->ip_qos_bulk == -1)
+#ifdef VMWARE_GUEST_WORKAROUND
+   if (vmwguest)
+   options->ip_qos_bulk = IPTOS_THROUGHPUT;
+   else
+#endif
options->ip_qos_bulk = IPTOS_DSCP_CS1;
if (options->request_tty == -1)
options->request_tty = REQUEST_TTY_AUTO;
diff --git a/secure/usr.bin/ssh/Makefile b/secure/usr.bin/ssh/Makefile
index 614cc7627fc5..023fa4a55be9 100644
--- a/secure/usr.bin/ssh/Makefile
+++ b/secure/usr.bin/ssh/Makefile
@@ -37,6 +37,9 @@ LIBADD+=  crypto
 CFLAGS+= -DXAUTH_PATH=\"${LOCALBASE}/bin/xauth\"
 .endif
 
+# Workaround VMware Workstation NAT bug
+CFLAGS+=-DVMWARE_GUEST_WORKAROUND
+
 .include 
 
 .PATH: ${SSHDIR}


signature.asc
Description: OpenPGP digital signature

Re: nda(4) does not work (reliably) in VMware Workstation

[Chuck Tuffli]

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,
>> >
>> > 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 as well in
>> VMware
>> > ESXi VMs.  Is this a problem with WS NVMe emulation?
>> >
>> >
>> > Since I don't have access to ESXi, the attached is a speculative fix. If
>> > it works, I'll clean this up a bit and get it committed. If not, please
>> > post the output from:
>> > nvmecontrol identtify nvme0
>>
>> Thank you, it seems to help (was seeing the issue previously immediately
>> after boot).  BTW, the ESXi VM works fine with nda, it's only the
>> Workstation that had the problem.  Comparing `nvmecontrol identify`
>> output from both, the only difference is (first is WS, second is ESXi):
>>
>> -Dataset Management Command:  Not Supported
>> +Dataset Management Command:  Supported
>>
>
> OK, that makes sense given the error message and the patch working. I'll
> get this cleaned up and committed. Thanks for the report!
>

Committed r342046 to address this

--chuck
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nda(4) does not work (reliably) in VMware Workstation

[Chuck Tuffli]

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 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 as well in
> VMware
> > ESXi VMs.  Is this a problem with WS NVMe emulation?
> >
> >
> > Since I don't have access to ESXi, the attached is a speculative fix. If
> > it works, I'll clean this up a bit and get it committed. If not, please
> > post the output from:
> > nvmecontrol identtify nvme0
>
> Thank you, it seems to help (was seeing the issue previously immediately
> after boot).  BTW, the ESXi VM works fine with nda, it's only the
> Workstation that had the problem.  Comparing `nvmecontrol identify`
> output from both, the only difference is (first is WS, second is ESXi):
>
> -Dataset Management Command:  Not Supported
> +Dataset Management Command:  Supported
>

OK, that makes sense given the error message and the patch working. I'll
get this cleaned up and committed. Thanks for the report!

--chuck
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nda(4) does not work (reliably) in VMware Workstation

[Chuck Tuffli]

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://people.freebsd.org/~yuripv/nda2.png
>
> nvd(4) works without issues in this VM.  nda(4) works as well in VMware
> ESXi VMs.  Is this a problem with WS NVMe emulation?
>

Since I don't have access to ESXi, the attached is a speculative fix. If it
works, I'll clean this up a bit and get it committed. If not, please post
the output from:
nvmecontrol identtify nvme0

--chuck
diff -r 1fbb2025b263 sys/cam/nvme/nvme_da.c
--- a/sys/cam/nvme/nvme_da.c	Sun Dec 09 21:53:45 2018 +
+++ b/sys/cam/nvme/nvme_da.c	Sun Dec 09 15:18:08 2018 -0800
@@ -798,7 +798,7 @@
 	disk->d_mediasize = (off_t)(disk->d_sectorsize * nsd->nsze);
 	disk->d_delmaxsize = disk->d_mediasize;
 	disk->d_flags = DISKFLAG_DIRECT_COMPLETION;
-//	if (cd->oncs.dsm) // XXX broken?
+	if ((cd->oncs >> NVME_CTRLR_DATA_ONCS_DSM_SHIFT) & NVME_CTRLR_DATA_ONCS_DSM_MASK)
 		disk->d_flags |= DISKFLAG_CANDELETE;
 	vwc_present = (cd->vwc >> NVME_CTRLR_DATA_VWC_PRESENT_SHIFT) &
 		NVME_CTRLR_DATA_VWC_PRESENT_MASK;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nda(4) does not work (reliably) in VMware Workstation

[Yuri Pankov]

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
> 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 as well in VMware
> ESXi VMs.  Is this a problem with WS NVMe emulation?
> 
> 
> Since I don't have access to ESXi, the attached is a speculative fix. If
> it works, I'll clean this up a bit and get it committed. If not, please
> post the output from:
> nvmecontrol identtify nvme0

Thank you, it seems to help (was seeing the issue previously immediately
after boot).  BTW, the ESXi VM works fine with nda, it's only the
Workstation that had the problem.  Comparing `nvmecontrol identify`
output from both, the only difference is (first is WS, second is ESXi):

-Dataset Management Command:  Not Supported
+Dataset Management Command:  Supported





signature.asc
Description: OpenPGP digital signature

nda(4) does not work (reliably) in VMware Workstation

[Yuri Pankov]

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 as well in VMware
ESXi VMs.  Is this a problem with WS NVMe emulation?



signature.asc
Description: OpenPGP digital signature

Re: failing to install 11.1R on VMWare

[Kevin Oberman]

Mercy! He probably assumed memory in GB and thought 4GB was plenty. Dumb
but understandable mistake. I've made similar ones, but try not to make a
habit of it. (My wife probably disagrees.)

Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

On Sat, Apr 7, 2018 at 4:31 AM, Ion-Mihai Tetcu <ite...@freebsd.org> wrote:

>
> [ combining 2 mails sent yesterday that didn't made it to the list ]
>
> Lol, looking over the one that fails ... RAM is set at 4MB. Which I
> think it might be the default on that cluster for some reason.
> I'll test now with a sane amount of RAM. Apologies for the noise.
>
> Yep, with 1GB it's OK.
> Can't wait for the next week to kill the guy who configured that VM
> before handling it over to me.
> Sorry again for waisting your time.
>
>
> On Fri, 6 Apr 2018 23:44:17 +0300
> Ion-Mihai Tetcu <ite...@freebsd.org> wrote:
>
> > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT)
> > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > > On 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" <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-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/output error
> > > > > > > > ...
> > > > > > > > (for 10.4R similar just with a different address).
> >
> >  [ .. ]
> >
> > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not
> > > > anything else) and got the same result trying to boot the 10.4R
> > > > boot-only ISO). Would it make any diff if I create the VM from
> > > > scratch on that host?
> > >
> > > Um, moving .vmx files around between versions of vsphere has to be
> > > done with a good deal of care, and given your having "issues" to
> > > start with I would not add that complexity to this problem.
> > >
> > > Create an new empty vm on 6.5.0, and use HW level 8, that is
> > > portable accross 5.5 to 6.5.
> > >
> > > Also try sticking with ONLY IDE disks and cdrom, that might
> > > be causing an issue.
> >
> > OK I created a new machine, almost with defaults (changed the disk to
> > IDE and independent-nonpersistent, put the CDROM on the same
> > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM
> > version 8) and the installer booted OK, got to the welcome screen.
> > I'll play more tomorrow since it's almost midnight and I have to be up
> > in 4h. Many thanks for the help.
> >
> >
> > Here's the vmx of it:
> > >>>
> > .encoding = "UTF-8"
> > config.version = "8"
> > virtualHW.version = "8"
> > nvram = "FREEBSD-test2.nvram"
> > pciBridge0.present = "TRUE"
> > svga.present = "TRUE"
> > pciBridge4.present = "TRUE"
> > pciBridge4.virtualDev = "pcieRootPort"
> > pciBridge4.functions = "8"
> > pciBridge5.present = "TRUE"
> > pciBridge5.virtualDev = "pcieRootPort"
> > pciBridge5.functions = "8"
> > pciBridge6.present = "TRUE"
> > pciBridge6.virtualDev = "pcieRootPort"
> > pciBridge6.functions = "8"
> > pciBridge7.present = "TRUE"
> > pciBridge7.virtualDev = "pcieRootPort"
> > pciBridge7.functions = "8"
> > vmci0.present = "TRUE"
> > hpet0.present = "TRUE"
> > memSize = "1024"
> > sched.cpu.units = "mhz"
> > sched.cpu.affinity = "all"
> > sched.

Re: failing to install 11.1R on VMWare

[Ion-Mihai Tetcu]

[ combining 2 mails sent yesterday that didn't made it to the list ]

Lol, looking over the one that fails ... RAM is set at 4MB. Which I
think it might be the default on that cluster for some reason.
I'll test now with a sane amount of RAM. Apologies for the noise.

Yep, with 1GB it's OK.
Can't wait for the next week to kill the guy who configured that VM
before handling it over to me.
Sorry again for waisting your time. 


On Fri, 6 Apr 2018 23:44:17 +0300
Ion-Mihai Tetcu <ite...@freebsd.org> wrote:

> On Fri, 6 Apr 2018 11:30:26 -0700 (PDT)
> "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > > On 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" <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-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/output error
> > > > > > > ...
> > > > > > > (for 10.4R similar just with a different address).  
> 
>  [ .. ]
> 
> > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not
> > > anything else) and got the same result trying to boot the 10.4R
> > > boot-only ISO). Would it make any diff if I create the VM from
> > > scratch on that host?
> > 
> > Um, moving .vmx files around between versions of vsphere has to be
> > done with a good deal of care, and given your having "issues" to
> > start with I would not add that complexity to this problem.
> > 
> > Create an new empty vm on 6.5.0, and use HW level 8, that is
> > portable accross 5.5 to 6.5.
> > 
> > Also try sticking with ONLY IDE disks and cdrom, that might
> > be causing an issue.   
> 
> OK I created a new machine, almost with defaults (changed the disk to
> IDE and independent-nonpersistent, put the CDROM on the same
> controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM
> version 8) and the installer booted OK, got to the welcome screen.
> I'll play more tomorrow since it's almost midnight and I have to be up
> in 4h. Many thanks for the help.
> 
> 
> Here's the vmx of it:
> >>>  
> .encoding = "UTF-8"
> config.version = "8"
> virtualHW.version = "8"
> nvram = "FREEBSD-test2.nvram"
> pciBridge0.present = "TRUE"
> svga.present = "TRUE"
> pciBridge4.present = "TRUE"
> pciBridge4.virtualDev = "pcieRootPort"
> pciBridge4.functions = "8"
> pciBridge5.present = "TRUE"
> pciBridge5.virtualDev = "pcieRootPort"
> pciBridge5.functions = "8"
> pciBridge6.present = "TRUE"
> pciBridge6.virtualDev = "pcieRootPort"
> pciBridge6.functions = "8"
> pciBridge7.present = "TRUE"
> pciBridge7.virtualDev = "pcieRootPort"
> pciBridge7.functions = "8"
> vmci0.present = "TRUE"
> hpet0.present = "TRUE"
> memSize = "1024"
> sched.cpu.units = "mhz"
> sched.cpu.affinity = "all"
> sched.cpu.latencySensitivity = "normal"
> sched.mem.affinity = "all"
> powerType.powerOff = "default"
> powerType.suspend = "default"
> powerType.reset = "default"
> scsi0.virtualDev = "lsilogic"
> scsi0.present = "TRUE"
> ide0:0.fileName = "FREEBSD-test2.vmdk"
> ide0:0.mode = "independent-nonpersistent"
> sched.ide0:0.shares = "normal"
> sched.ide0:0.throughputCap = "off"
> ide0:0.present = "TRUE"
> ethernet0.virtualDev = "e1000"
> ethernet0.networkName = "VM Network"
> ethernet0.addressType = "vpx"
> ethernet0.generatedAddress = "00:50:56:8d:99:50"
> ethernet0.present = "TRUE"
> ide0:1.deviceType = "cdrom-image

Re: failing to install 11.1R on VMWare

[Rodney W. Grimes]

> Lol, looking over the one that fails ... RAM is set at 4MB. Which I
> think it might be the default on that cluster for some reason.
> I'll test now with a sane amount of RAM. Apologies for the noise.
> 
> On Fri, 6 Apr 2018 23:44:17 +0300
> Ion-Mihai Tetcu <ite...@freebsd.org> wrote:
> 
> > On Fri, 6 Apr 2018 11:30:26 -0700 (PDT)
> > "Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > 
> > > > On 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" <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-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/output error
> > > > > > > > ...
> > > > > > > > (for 10.4R similar just with a different address).  
> > 
> >  [ .. ]
> > 
> > > > I relocated the VM on one of the 6.5.0 hosts (just the VM, not
> > > > anything else) and got the same result trying to boot the 10.4R
> > > > boot-only ISO). Would it make any diff if I create the VM from
> > > > scratch on that host?
> > > 
> > > Um, moving .vmx files around between versions of vsphere has to be
> > > done with a good deal of care, and given your having "issues" to
> > > start with I would not add that complexity to this problem.
> > > 
> > > Create an new empty vm on 6.5.0, and use HW level 8, that is
> > > portable accross 5.5 to 6.5.
> > > 
> > > Also try sticking with ONLY IDE disks and cdrom, that might
> > > be causing an issue.   
> > 
> > OK I created a new machine, almost with defaults (changed the disk to
> > IDE and independent-nonpersistent, put the CDROM on the same
> > controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM
> > version 8) and the installer booted OK, got to the welcome screen.
> > I'll play more tomorrow since it's almost midnight and I have to be up
> > in 4h. Many thanks for the help.
> > 
> > 
> > Here's the vmx of it:
> > >>>  
> > .encoding = "UTF-8"
> > config.version = "8"
> > virtualHW.version = "8"
> > nvram = "FREEBSD-test2.nvram"
> > pciBridge0.present = "TRUE"
> > svga.present = "TRUE"
> > pciBridge4.present = "TRUE"
> > pciBridge4.virtualDev = "pcieRootPort"
> > pciBridge4.functions = "8"
> > pciBridge5.present = "TRUE"
> > pciBridge5.virtualDev = "pcieRootPort"
> > pciBridge5.functions = "8"
> > pciBridge6.present = "TRUE"
> > pciBridge6.virtualDev = "pcieRootPort"
> > pciBridge6.functions = "8"
> > pciBridge7.present = "TRUE"
> > pciBridge7.virtualDev = "pcieRootPort"
> > pciBridge7.functions = "8"
> > vmci0.present = "TRUE"
> > hpet0.present = "TRUE"
> > memSize = "1024"

that would be 1024MB, so 1G


> > sched.cpu.units = "mhz"
> > sched.cpu.affinity = "all"
> > sched.cpu.latencySensitivity = "normal"
> > sched.mem.affinity = "all"
> > powerType.powerOff = "default"
> > powerType.suspend = "default"
> > powerType.reset = "default"
> > scsi0.virtualDev = "lsilogic"
> > scsi0.present = "TRUE"
> > ide0:0.fileName = "FREEBSD-test2.vmdk"
> > ide0:0.mode = "independent-nonpersistent"
> > sched.ide0:0.shares = "normal"
> > sched.ide0:0.throughputCap = "off"
> > ide0:0.present = "TRUE"
> > ethernet0.vir

Re: failing to install 11.1R on VMWare

[Ion-Mihai Tetcu]

On Fri, 6 Apr 2018 11:30:26 -0700 (PDT)
"Rodney W. Grimes" <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > On 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" <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-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/output error
> > > > > > ...
> > > > > > (for 10.4R similar just with a different address).

 [ .. ]

> > I relocated the VM on one of the 6.5.0 hosts (just the VM, not
> > anything else) and got the same result trying to boot the 10.4R
> > boot-only ISO). Would it make any diff if I create the VM from
> > scratch on that host?  
> 
> Um, moving .vmx files around between versions of vsphere has to be
> done with a good deal of care, and given your having "issues" to
> start with I would not add that complexity to this problem.
> 
> Create an new empty vm on 6.5.0, and use HW level 8, that is portable
> accross 5.5 to 6.5.
> 
> Also try sticking with ONLY IDE disks and cdrom, that might
> be causing an issue. 

OK I created a new machine, almost with defaults (changed the disk to
IDE and independent-nonpersistent, put the CDROM on the same
controller) on 6.5.0 with Compatibility set to ESXi 5.0 and later (VM
version 8) and the installer booted OK, got to the welcome screen.
I'll play more tomorrow since it's almost midnight and I have to be up
in 4h. Many thanks for the help.


Here's the vmx of it:
>>>
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
nvram = "FREEBSD-test2.nvram"
pciBridge0.present = "TRUE"
svga.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
memSize = "1024"
sched.cpu.units = "mhz"
sched.cpu.affinity = "all"
sched.cpu.latencySensitivity = "normal"
sched.mem.affinity = "all"
powerType.powerOff = "default"
powerType.suspend = "default"
powerType.reset = "default"
scsi0.virtualDev = "lsilogic"
scsi0.present = "TRUE"
ide0:0.fileName = "FREEBSD-test2.vmdk"
ide0:0.mode = "independent-nonpersistent"
sched.ide0:0.shares = "normal"
sched.ide0:0.throughputCap = "off"
ide0:0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "vpx"
ethernet0.generatedAddress = "00:50:56:8d:99:50"
ethernet0.present = "TRUE"
ide0:1.deviceType = "cdrom-image"
ide0:1.fileName = 
"/vmfs/volumes/59258945-94251612-6fa4-3c4a92e1d6b8/ISO/FreeBSD-11.1-RELEASE-amd64-bootonly.iso"
ide0:1.present = "TRUE"
floppy0.startConnected = "FALSE"
floppy0.clientDevice = "TRUE"
floppy0.fileName = "vmware-null-remote-floppy"
displayName = "FREEBSD-test2"
guestOS = "freebsd-64"
toolScripts.afterPowerOn = "TRUE"
toolScripts.afterResume = "TRUE"
toolScripts.beforeSuspend = "TRUE"
toolScripts.beforePowerOff = "TRUE"
uuid.bios = "42 0d 6c 09 83 cf 81 5d-12 6d a8 de 4d 1a 3a d6"
vc.uuid = "50 0d 05 1e 9d 59 64 6a-c5 a8 b4 1b b4 f6 55 9a"
migrate.hostLog = "FREEBSD-test2-490e49c9.hlog"
sched.cpu.min = "0"
sched.cpu.shares = "normal"
sched.mem.min = "0"
sched.mem.minSize = "0"
sched.mem.shares = "normal"
numa.autosize.vcpu.maxPerVirtualNode = "1"
numa.auto

Re: failing to install 11.1R on VMWare

[Matthew Grooms]

On 4/6/2018 12:40 PM, Ion-Mihai Tetcu wrote:

On 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" <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-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/output error
...
(for 10.4R similar just with a different address).

SCSI Adapatr for the VM is set to LSI Logic (but I've tried
with the other available options with the same result).

VMWare docs list both 10 and 11 as being compatible with this
version of ESXi.
Any pointers to get through this will be greatly appreciated, I
didn't found anything on the net, and I need a sane system to
play with when I'm getting tired of the ton of Linux distros
I'm forced to use.

Try setting the BIOS emulation to BIOS instead of UEFI.

The WM is set:
Firmware: BIOS.
Boot Delay: 0ms
Force BIOS setup: No
Failed boot recovery: Do not automatically retry after virtual
machine fails to find a boot device EFI Secure Boot: Disabled

Those all look good from my experience.


And what image are you trying to boot from?
Are you trying to boot from a cd attached via vsphere client? or
is it a file on the server?

I've uploaded the ISOs on one of the data stores on the server,
didn't even tried from the client.

Ok, so that is also the same procedure I am trying.

Now, which .ISO is it?  Maybe you have a broken snapshots.  Lots of
bootcode work has been going on in -current.  Can you try the 11.1
release ISO either i386 or amd64?

I know that installs as I have done that many times.

FreeBSD-11.1-RELEASE-amd64-dvd1.iso
FreeBSD-11.1-RELEASE-amd64-bootonly.iso
Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso

I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the
data store and checked the sha256 against the one on the ftp site and
it's OK, so except if vshpere somehow corrupts files on upload and
fixes them on download I think the image is OK.
  

I usually use a .ISO when working with ESXi and FreeBSD as a
guest.

I'll try with the vmdk image of the release now.

I have NOT ever tried that, so have no data there.


I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any
6.0.0.

Hm, I guess I could try on 6.5 as an other cluster with has hosts
running VMware ESXi, 6.5.0, 4564106

It should just work, I have played with ESXi 6.0.0 at one
time or another and would have a good recollection if I had issues
booting any FreeBSD distributions on it.  At present I do not have
any 6.0.0 running, though I could fix that in a matter of minutes.
  
I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything

else) and got the same result trying to boot the 10.4R boot-only ISO).
Would it make any diff if I create the VM from scratch on that host?



I have about 40 FreeBSD 10.3/10.4 VMs that were installed on a vSphere 
ESXi v6.0 cluster that has since been upgraded recently to v6.5. As a 
test, I just booted 11.1 from an ISO ( FreeBSD-11.1-RELEASE-amd64-disc1 
) using the FreeBSD-64bit OS template defaults and it reaches the 
installer welcome screen without issue. Here is a copy of the vmx file 
if you'd like to compare. Perhaps your host is selecting a different set 
of defaults for some reason? ...


[root@esxi1:/vmfs/volumes/552c8e27-b1f51fec-9bf8-90e2ba090e50/test-freebsd11] 
cat test-freebsd11.vmx

.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "13"
nvram = "test-freebsd11.nvram"
pciBridge0.present = "TRUE"
svga.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
floppy0.present = "FALSE"
numvcpus = "2"
memSize = "2048"
sched.cpu.units = "mhz"
sched.cpu.affinity = "all"
tools.upgrade.policy = "manual"
scsi0.virtualDev = "lsilogic"
scsi0.present = "TRUE"
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "test-freebsd11.vmdk"
sched.scsi0:0.shares = "normal"
sched.scsi0:0.throughputCap = "off"
scsi0:0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.networkN

Re: failing to install 11.1R on VMWare

[Rainer Duffner]

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
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: failing to install 11.1R on VMWare

[Rodney W. Grimes]

> On 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" <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-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/output error
> > > > > ...
> > > > > (for 10.4R similar just with a different address).
> > > > > 
> > > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried
> > > > > with the other available options with the same result).
> > > > > 
> > > > > VMWare docs list both 10 and 11 as being compatible with this
> > > > > version of ESXi.
> > > > > Any pointers to get through this will be greatly appreciated, I
> > > > > didn't found anything on the net, and I need a sane system to
> > > > > play with when I'm getting tired of the ton of Linux distros
> > > > > I'm forced to use.
> > > > 
> > > > Try setting the BIOS emulation to BIOS instead of UEFI.  
> > > 
> > > The WM is set:
> > > Firmware: BIOS.
> > > Boot Delay: 0ms
> > > Force BIOS setup: No
> > > Failed boot recovery: Do not automatically retry after virtual
> > > machine fails to find a boot device EFI Secure Boot: Disabled  
> > 
> > Those all look good from my experience.
> > 
> > > > And what image are you trying to boot from?
> > > > Are you trying to boot from a cd attached via vsphere client? or
> > > > is it a file on the server?  
> > > 
> > > I've uploaded the ISOs on one of the data stores on the server,
> > > didn't even tried from the client.  
> > 
> > Ok, so that is also the same procedure I am trying.
> > 
> > Now, which .ISO is it?  Maybe you have a broken snapshots.  Lots of
> > bootcode work has been going on in -current.  Can you try the 11.1
> > release ISO either i386 or amd64?
> > 
> > I know that installs as I have done that many times.
> 
> FreeBSD-11.1-RELEASE-amd64-dvd1.iso
> FreeBSD-11.1-RELEASE-amd64-bootonly.iso
> Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso
> 
> I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the
> data store and checked the sha256 against the one on the ftp site and
> it's OK, so except if vshpere somehow corrupts files on upload and
> fixes them on download I think the image is OK.

And of somewhat known status, I usually use the disc1, but that
should not matter... unless the dvd emulation is scewing things
up.  But the bootonly.iso should be fine, that is under 700MB

> > > > I usually use a .ISO when working with ESXi and FreeBSD as a
> > > > guest.  
> > > 
> > > I'll try with the vmdk image of the release now.  
> > 
> > I have NOT ever tried that, so have no data there.
> > 
> > > > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any
> > > > 6.0.0.  
> > > 
> > > Hm, I guess I could try on 6.5 as an other cluster with has hosts
> > > running VMware ESXi, 6.5.0, 4564106  
> > 
> > It should just work, I have played with ESXi 6.0.0 at one
> > time or another and would have a good recollection if I had issues
> > booting any FreeBSD distributions on it.  At present I do not have
> > any 6.0.0 running, though I could fix that in a matter of minutes.
>  
> I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything
> else) and got the same result trying to boot the 10.4R boot-only ISO).
> Would it make any diff if I create the VM from scratch on that host?

Um, moving .vmx files around between versions of vsphere has to be
done with a good deal of care, and given your having "issues" to
start with I would not add that complexity to this problem.

Create an new empty vm on 6.5.0, and use HW level 8, that is portable
accross 5.5 to 6.5.

Also try sticking with ONLY IDE disks and cdrom, that might
be causing an issue. 

Then if it fails send me the .vmx file for the VM so I can look at
it for differences in what I am using to seeing.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: failing to install 11.1R on VMWare

[Ion-Mihai Tetcu]

On 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" <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-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/output error
> > > > ...
> > > > (for 10.4R similar just with a different address).
> > > > 
> > > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried
> > > > with the other available options with the same result).
> > > > 
> > > > VMWare docs list both 10 and 11 as being compatible with this
> > > > version of ESXi.
> > > > Any pointers to get through this will be greatly appreciated, I
> > > > didn't found anything on the net, and I need a sane system to
> > > > play with when I'm getting tired of the ton of Linux distros
> > > > I'm forced to use.
> > > 
> > > Try setting the BIOS emulation to BIOS instead of UEFI.  
> > 
> > The WM is set:
> > Firmware: BIOS.
> > Boot Delay: 0ms
> > Force BIOS setup: No
> > Failed boot recovery: Do not automatically retry after virtual
> > machine fails to find a boot device EFI Secure Boot: Disabled  
> 
> Those all look good from my experience.
> 
> > > And what image are you trying to boot from?
> > > Are you trying to boot from a cd attached via vsphere client? or
> > > is it a file on the server?  
> > 
> > I've uploaded the ISOs on one of the data stores on the server,
> > didn't even tried from the client.  
> 
> Ok, so that is also the same procedure I am trying.
> 
> Now, which .ISO is it?  Maybe you have a broken snapshots.  Lots of
> bootcode work has been going on in -current.  Can you try the 11.1
> release ISO either i386 or amd64?
> 
> I know that installs as I have done that many times.

FreeBSD-11.1-RELEASE-amd64-dvd1.iso
FreeBSD-11.1-RELEASE-amd64-bootonly.iso
Tried this one after 11.1 failed FreeBSD-10.4-RELEASE-amd64-bootonly.iso

I just downloaded the FreeBSD-11.1-RELEASE-amd64-bootonly.iso from the
data store and checked the sha256 against the one on the ftp site and
it's OK, so except if vshpere somehow corrupts files on upload and
fixes them on download I think the image is OK.
 
> > > I usually use a .ISO when working with ESXi and FreeBSD as a
> > > guest.  
> > 
> > I'll try with the vmdk image of the release now.  
> 
> I have NOT ever tried that, so have no data there.
> 
> > > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any
> > > 6.0.0.  
> > 
> > Hm, I guess I could try on 6.5 as an other cluster with has hosts
> > running VMware ESXi, 6.5.0, 4564106  
> 
> It should just work, I have played with ESXi 6.0.0 at one
> time or another and would have a good recollection if I had issues
> booting any FreeBSD distributions on it.  At present I do not have
> any 6.0.0 running, though I could fix that in a matter of minutes.
 
I relocated the VM on one of the 6.5.0 hosts (just the VM, not anything
else) and got the same result trying to boot the 10.4R boot-only ISO).
Would it make any diff if I create the VM from scratch on that host?


Tnx,

-- 
IOnut Tetcu

 


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: failing to install 11.1R on VMWare

[Rodney W. Grimes]

> 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-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/output error
> > > ...
> > > (for 10.4R similar just with a different address).
> > > 
> > > SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the
> > > other available options with the same result).
> > > 
> > > VMWare docs list both 10 and 11 as being compatible with this
> > > version of ESXi.
> > > Any pointers to get through this will be greatly appreciated, I
> > > didn't found anything on the net, and I need a sane system to play
> > > with when I'm getting tired of the ton of Linux distros I'm forced
> > > to use.  
> > 
> > Try setting the BIOS emulation to BIOS instead of UEFI.
> 
> The WM is set:
> Firmware: BIOS.
> Boot Delay: 0ms
> Force BIOS setup: No
> Failed boot recovery: Do not automatically retry after virtual machine fails 
> to find a boot device
> EFI Secure Boot: Disabled

Those all look good from my experience.

> > And what image are you trying to boot from?
> > Are you trying to boot from a cd attached via vsphere client? or
> > is it a file on the server?
> 
> I've uploaded the ISOs on one of the data stores on the server, didn't
> even tried from the client.

Ok, so that is also the same procedure I am trying.

Now, which .ISO is it?  Maybe you have a broken snapshots.  Lots of
bootcode work has been going on in -current.  Can you try the 11.1
release ISO either i386 or amd64?

I know that installs as I have done that many times.

> > I usually use a .ISO when working with ESXi and FreeBSD as a guest.
> 
> I'll try with the vmdk image of the release now.

I have NOT ever tried that, so have no data there.

> > I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0.
> 
> Hm, I guess I could try on 6.5 as an other cluster with has hosts
> running VMware ESXi, 6.5.0, 4564106

It should just work, I have played with ESXi 6.0.0 at one
time or another and would have a good recollection if I had issues
booting any FreeBSD distributions on it.  At present I do not have
any 6.0.0 running, though I could fix that in a matter of minutes.

-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: failing to install 11.1R on VMWare

[Ion-Mihai Tetcu]

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-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/output error
> > ...
> > (for 10.4R similar just with a different address).
> > 
> > SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the
> > other available options with the same result).
> > 
> > VMWare docs list both 10 and 11 as being compatible with this
> > version of ESXi.
> > Any pointers to get through this will be greatly appreciated, I
> > didn't found anything on the net, and I need a sane system to play
> > with when I'm getting tired of the ton of Linux distros I'm forced
> > to use.  
> 
> Try setting the BIOS emulation to BIOS instead of UEFI.

The WM is set:
Firmware: BIOS.
Boot Delay: 0ms
Force BIOS setup: No
Failed boot recovery: Do not automatically retry after virtual machine fails to 
find a boot device
EFI Secure Boot: Disabled

> And what image are you trying to boot from?
> Are you trying to boot from a cd attached via vsphere client? or
> is it a file on the server?

I've uploaded the ISOs on one of the data stores on the server, didn't
even tried from the client.

> I usually use a .ISO when working with ESXi and FreeBSD as a guest.

I'll try with the vmdk image of the release now.

> I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0.

Hm, I guess I could try on 6.5 as an other cluster with has hosts
running VMware ESXi, 6.5.0, 4564106

-- 
IOnut




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: failing to install 11.1R on VMWare

[Rodney W. Grimes]

> 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': input/output error
> ...
> (for 10.4R similar just with a different address).
> 
> SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the
> other available options with the same result).
> 
> VMWare docs list both 10 and 11 as being compatible with this version
> of ESXi.
> Any pointers to get through this will be greatly appreciated, I didn't
> found anything on the net, and I need a sane system to play with when
> I'm getting tired of the ton of Linux distros I'm forced to use.

Try setting the BIOS emulation to BIOS instead of UEFI.

And what image are you trying to boot from?
Are you trying to boot from a cd attached via vsphere client? or
is it a file on the server?

I usually use a .ISO when working with ESXi and FreeBSD as a guest.

I run these guest on ESXi 5.5 and ESXi 6.5, I do not have any 6.0.0.


-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

failing to install 11.1R on VMWare

[Ion-Mihai Tetcu]

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': input/output error
...
(for 10.4R similar just with a different address).

SCSI Adapatr for the VM is set to LSI Logic (but I've tried with the
other available options with the same result).

VMWare docs list both 10 and 11 as being compatible with this version
of ESXi.
Any pointers to get through this will be greatly appreciated, I didn't
found anything on the net, and I need a sane system to play with when
I'm getting tired of the ton of Linux distros I'm forced to use.


Tnx,

-- 
IOnut Tetcu




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Call for testing VMware open-vm-tools update

[Josh Paetzel]

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, and there was a kernel panic that
affected HEAD/amd64.  That has been addressed and vmware has started QA
for the tools for FreeBSD 11.1-R and 10.3-R  amd64 and i386.

I've given this update a fair amount of testing and it gets a "works on
my machine" certification from me.

The new version is available as a port at
https://people.freebsd.org/~jpaetzel/open-vm-tools.tar.gz . Feel free to
give it a spin and please report any issues by filing a bug at
https://bugs.freebsd.org/   If you tag the bug you create as ports
emulators/open-vm-tools it will get auto-assigned to me.

-- 

Thanks,

Josh Paetzel
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ALPHA4-amd64-r301975 UFS crashes on VMware Wks

[Merljin]

Hello community,
( sorry for my bad english lang skills )
I would like to report problem with
FreeBSD-11.0-ALPHA4-amd64-20160617-r301975.

After clean install, while trying to install any binary packages with pkg
(ex: pkg install xorg )
Kernel crashes happen usually during any disk intensive operation.

( pkg upgrade wanted to upgrade two packages - get text and python27 )
Crash occured immediatelly after confirming pkg to continue ( y/N )

Jun 21 18:53:58 Auriga pkg: gettext-runtime upgraded: 0.19.7 -> 0.19.8.1
Jun 21 18:53:59 Auriga kernel: lock order reversal:
Jun 21 18:53:59 Auriga kernel: 1st 0xf80033631068 ufs (ufs) @
/usr/src/sys/kern/vfs_subr.c:2498
Jun 21 18:53:59 Auriga kernel: 2nd 0xfe00f625e170 bufwait (bufwait) @
/usr/src/sys/ufs/ffs/ffs_vnops.c:263
Jun 21 18:53:59 Auriga kernel: 3rd 0xf80033499068 ufs (ufs) @
/usr/src/sys/kern/vfs_subr.c:2498
Jun 21 18:53:59 Auriga kernel: stack backtrace:
Jun 21 18:53:59 Auriga kernel: #0 0x80aa7320 at
witness_debugger+0x70
Jun 21 18:53:59 Auriga kernel: #1 0x80aa7214 at
witness_checkorder+0xe54
Jun 21 18:53:59 Auriga kernel: #2 0x80a206d2 at __lockmgr_args+0x4c2
Jun 21 18:53:59 Auriga kernel: #3 0x80d09426 at ffs_lock+0xa6
Jun 21 18:53:59 Auriga kernel: #4 0x81014f2a at VOP_LOCK1_APV+0xea
Jun 21 18:53:59 Auriga kernel: #5 0x80b17b8a at _vn_lock+0x9a
Jun 21 18:53:59 Auriga kernel: #6 0x80b07fb3 at vget+0x63
Jun 21 18:53:59 Auriga kernel: #7 0x80afa84c at vfs_hash_get+0xcc
Jun 21 18:53:59 Auriga kernel: #8 0x80d05130 at ffs_vgetf+0x40
Jun 21 18:53:59 Auriga kernel: #9 0x80cfca21 at
softdep_sync_buf+0xb51
Jun 21 18:53:59 Auriga kernel: #10 0x80d0a016 at ffs_syncvnode+0x256
Jun 21 18:53:59 Auriga kernel: #11 0x80ce0d83 at ffs_truncate+0x8d3
Jun 21 18:53:59 Auriga kernel: #12 0x80d11741 at ufs_direnter+0x681
Jun 21 18:53:59 Auriga kernel: #13 0x80d1aa59 at ufs_makeinode+0x5e9
Jun 21 18:53:59 Auriga kernel: #14 0x80d165e3 at ufs_create+0x33
Jun 21 18:53:59 Auriga kernel: #15 0x8101281b at VOP_CREATE_APV+0xdb
Jun 21 18:53:59 Auriga kernel: #16 0x80b173d8 at vn_open_cred+0x2f8
Jun 21 18:53:59 Auriga kernel: #17 0x80b1075c at kern_openat+0x25c
Jun 21 18:54:01 Auriga pkg: python27 upgraded: 2.7.11_2 -> 2.7.11_3


After executing "pkg install xorg" - 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 ?

Karel
( FBSD newbie )
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[O. Hartmann]

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 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 so I'm hoping that individuals who
> >> have committed in the last 24 hours will have some idea of their
> >> changes having such an impact.  
> > 
> > For me (BIOS boot at DELL notebook) is broken after jump
> > from r300062 to r300158. CapsLock works, but ^T shows nothing.
> > Here is a photo (sorry for the quality):
> > ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
> > 
> > Boot with r300062 works fine.  
> 
> A wild guess (not really), try to revert r300113
> 

We updated several systems of different ages and CPU generations
(around 10) to 300158. Bare metal. The systems all failed to boot, they
got stuck after the USB system has been probed (according to the kernel
messages). Some boxes get stuck after the message of the generation of
the UUID occured. Pushing the Powerbutton performs a clean shutdown,
although - so te system seems still alive, but usually the power is
turning off - this time, the box is stuck with the uptime message.

On random reboots some of the boxes boot. But the desaster then starts.
The network is highly unstable and flaky - while I can ping hosts or
resolve their IP by a DNS, I can not login via ssh, the webservices of
the webserver of the machines in question are inaccessible as well as
their databases (PostgreSQL) as well as ssh.

And it is more frustrating: I can't update or go back with svn
(either /usr/bin/svn or /usr/local/bin/svn) within the sources to
avoid this mess. In all cases, svn "times out".

Accessing the web from clients with the broken CURRENT code also ends
up in a wild guess game: sometimes the connection to services can be
established, sometimes not and I see a timeout. With svn
in /usr/src, on one box I could obtain a poor fragment of the code via
"svn update -r 35" (35 was in my case the starting point when
everything was up an running and working).

In short words: reverting back to r300113 isn't possible on the most
systems!

This problem has been present immediately after 300158 has been
introduced and build-world/build-kernel has been performed and the
fact, that different hardware, including NICs, has been affected, does
not narrow down the problem to a specific NIC, CPU type or hardware.
And that leads me to the question whether the code injected into
CURRENT gets tested - or not. If there would be a test, I guess the
problem would have revealed itself immediately.

I boot via UEFI as well as BIOS - the problem is with both.

In such a case as described with a nonworking svn, how am I supposed
to revert to the supposedly working revision r300113?

Kind regards and thanks in advance for your suggestions,

O. Hartmann 


P.S.

I'm using IPFW on all systems. Disabling IPFW (ipfw disable firewall) seems to 
releafe
the symptoms a bit - no matter whether custom scripts were used or the settings 
from
rc.conf.


pgpiWgUnpJr8J.pgp
Description: OpenPGP digital signature

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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 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 so I'm hoping that individuals who
> have committed in the last 24 hours will have some idea of their
> changes having such an impact.

 For me (BIOS boot at DELL notebook) is broken after jump
 from r300062 to r300158. CapsLock works, but ^T shows nothing.
 Here is a photo (sorry for the quality):
 ftp://ftp.wart.ru/pub/misc/boot_broken.jpg

 Boot with r300062 works fine.
>>>
>>> A wild guess (not really), try to revert r300113
>>
>> Tried that, conflict on reverting this single revision and an error
>> compiling kernel. (No more details, sorry, busy at work for now)
>>
> 
> Alexander has committed a fix, so upgrading to the latest version can be a
> better strategy now.

Yep, I've updated the kernel to r300212 and it works.

Thanks all!
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[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 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 so I'm hoping that individuals who
 have committed in the last 24 hours will have some idea of their
 changes having such an impact.
>>>
>>> For me (BIOS boot at DELL notebook) is broken after jump
>>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>>> Here is a photo (sorry for the quality):
>>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>>
>>> Boot with r300062 works fine.
>>
>> A wild guess (not really), try to revert r300113
> 
> Tried that, conflict on reverting this single revision and an error
> compiling kernel. (No more details, sorry, busy at work for now)
> 

Alexander has committed a fix, so upgrading to the latest version can be a
better strategy now.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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 [piperd]. ddb just shows the
>>> shell as hanging in piperead. Diffing between those two revisions I
>>> don't see any obvious offenders so I'm hoping that individuals who
>>> have committed in the last 24 hours will have some idea of their
>>> changes having such an impact.
>>
>> For me (BIOS boot at DELL notebook) is broken after jump
>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>> Here is a photo (sorry for the quality):
>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>
>> Boot with r300062 works fine.
> 
> A wild guess (not really), try to revert r300113

Tried that, conflict on reverting this single revision and an error
compiling kernel. (No more details, sorry, busy at work for now)

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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 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 so I'm hoping that individuals who
>>> have committed in the last 24 hours will have some idea of their
>>> changes having such an impact.
>>
>> For me (BIOS boot at DELL notebook) is broken after jump
>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>> Here is a photo (sorry for the quality):
>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>
>> Boot with r300062 works fine.
> 
> Break into ddb and show the 'ps' command output.

Here are some photoes: ftp://ftp.wart.ru/pub/misc/Boot/
Notes:
1. The third one is none-readable. :-( I'll redo it if needed
(but not right now).
2. The last but one screens are nearly identical (modulo integers)
and were skipped.

BTW, if detach all devices from the notebook (external screen,
wired network, usb extentions) the notebook can boot ones out of
10 times.

HTH
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[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 [piperd]. ddb just shows the
>> shell as hanging in piperead. Diffing between those two revisions I
>> don't see any obvious offenders so I'm hoping that individuals who
>> have committed in the last 24 hours will have some idea of their
>> changes having such an impact.
> 
> For me (BIOS boot at DELL notebook) is broken after jump
> from r300062 to r300158. CapsLock works, but ^T shows nothing.
> Here is a photo (sorry for the quality):
> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
> 
> Boot with r300062 works fine.

A wild guess (not really), try to revert r300113

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[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 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 so I'm hoping that individuals who
> > have committed in the last 24 hours will have some idea of their
> > changes having such an impact.
> 
> For me (BIOS boot at DELL notebook) is broken after jump
> from r300062 to r300158. CapsLock works, but ^T shows nothing.
> Here is a photo (sorry for the quality):
> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
> 
> Boot with r300062 works fine.

Break into ddb and show the 'ps' command output.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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 revisions I
> don't see any obvious offenders so I'm hoping that individuals who
> have committed in the last 24 hours will have some idea of their
> changes having such an impact.

For me (BIOS boot at DELL notebook) is broken after jump
from r300062 to r300158. CapsLock works, but ^T shows nothing.
Here is a photo (sorry for the quality):
ftp://ftp.wart.ru/pub/misc/boot_broken.jpg

Boot with r300062 works fine.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

boot broken on VMWare somewhere between r300069 and r300176

[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 revisions I
don't see any obvious offenders so I'm hoping that individuals who
have committed in the last 24 hours will have some idea of their
changes having such an impact.

Thanks in advance.

-M
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 5/11/2016 2:12 AM, Edward Tomasz Napierała wrote:

On 0510T1522, Matthew Grooms wrote:


The PR 204901 filed for this can be closed now that the author (ahem)
has committed support for the camcontrol reprobe command ...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204901
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=866020+0+current/svn-src-head


Ugh.  I honestly have no idea how did I manage to miss your patch.
I did remember the discussion, I remember asking mav@ about what's the
best way to hook it up to CAM, but until yesterday I just didn't know
the patch (and the PR) existed.  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, it would be great if someone 
could get the VMware PVSCSI driver into the tree for the 11.0 release. 
It's sitting in phabricator in review and I'm sure it would be useful to 
a bunch of FreeBSD users ...


https://reviews.freebsd.org/D4112

Thanks,

-Matthew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Resizing a zpool as a VMware ESXi guest ...

[Edward Tomasz Napierała]

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 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 Attention' sense information in
> >>> response to a 'Read Capacity' request. This kinda makes sense as ESXi
> >>> emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09
> >>> ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't
> >>> defined until the SCSCI-3 spec. It's frustrating that the only way to
> >>> get the scsci_da code to call reprobe() is by receiving a command
> >>> from the device. Would something like this work? ...
> >>>
> >>> 1) Register a callback using xpt_register_async( daasync,
> >>> AC_REPROBE_DEVICE, path ) that calls reprobe()
> >>> 2) Implement a new IOCTL in cam_xpt that camcontrol can call with the
> >>> bus:target:lun as the argument
> >>> 3) have cam_xpt capture the IOCTL request and call xpt_async(
> >>> AC_REPROBE_DEVICE, path ) as a result
> >>>
> >>> This way users would have the option of manually asking cam to
> >>> communicate the new size to geom. The only option now is one or more
> >>> reboots to gain access to the increased disk capacity. If this sounds
> >>> like a reasonable approach, I'll take a stab at implementing it.
> >>>
> >>
> >> Here is a proof of concept patch. I'm a complete noob when it comes to
> >> cam, scsi or freebsd kernel development for that matter, so I'm sure
> >> it could have been done a better way. In any case, I added a new
> >> command to camcontrol that allows you to specify a bus, target and lun
> >> as an argument. For example ...
> >>
> >> # camcontrol readcap da1 -h
> >> Device Size: 32 G, Block Length: 512 bytes
> >>
> >> # gpart show da1
> >> =>  40  58720176  da1  GPT  (28G)
> >> 40  587201761  freebsd-ufs  (28G)
> >>
> >> Note, I resized the VMDK disk in ESXi. The camcontrol output shows the
> >> size as 32G but geom thinks its 28G.
> >>
> >> # camcontrol devlist
> >>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)
> >>
> >> # camcontrol reprobe 2:1:0
> >>
> >> This generates an event that is captured by the scsci da device to
> >> forces a reprobe. The kernel output looks almost identical to when the
> >> 'Unit Attention' sense data is received ...
> >>
> >> Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
> >> Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
> >> Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes
> >> or `gpart undo da1` to revert them.
> >>
> >> Now that geom knows about the increased disk capacity, I can increase
> >> the partition size and grow the fs ...
> >>
> >> [root@iscsi-i /home/mgrooms]# gpart show da1
> >> =>  40  67108784  da1  GPT  (32G)
> >> 40  587201761  freebsd-ufs  (28G)
> >>   58720216   8388608   - free -  (4.0G)
> >>
> >> # gpart resize -i 1 da1
> >> da1p1 resized
> >>
> >> # growfs da1p1
> >> Device is mounted read-write; resizing will result in temporary write
> >> suspension for /var/data1.
> >> It's strongly recommended to make a backup before growing the file
> >> system.
> >> OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB
> >> to 32GB? [Yes/No] Yes
> >> super-block backups (for fsck_ffs -b #) at:
> >>  58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672
> >>
> >> # df -h
> >> FilesystemSizeUsed   Avail Capacity  Mounted on
> >> /dev/da0p3 18G5.3G 12G31%/
> >> devfs 1.0K1.0K  0B   100%/dev
> >> /dev/da1p1 31G 32M 28G 0%/var/data1
> >> /dev/da2p1 15G 32M 14G 0%/var/data2
> >>
> >> Sure would be nice to have something like this in the tree. It's
> >> really a drag to have to reboot production VMs to increase disk
> >> capacity when it could be easily avoided. I'm not sure what the
> >> correct IOCTL should look like. Maybe CAMIOCOMMAND is a better way to
> >> go? If someone with some experience with the cam/scsi subsystems was
> >> willing to give me some direction I'd be willing to try and rewrite
> >> the patch in a way that would be commit worthy. I just need some
> >> direction.
> >>
> >
> > Ok, last post until I get some feedback. Here's a new version of the
> > patch complete with man page updates. It communicates via CAMIOCOMMAND
> > instead of introducing a new ioctl value. I tried to model it after the
> > device reset option, hopefully with some degree of success. Functionally
> > it should be the same as the first patch.
> >
> 
> The PR 

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

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, It's obvious that Edward was correct in assuming
that ESXi doesn't return any 'Unit Attention' sense information in
response to a 'Read Capacity' request. This kinda makes sense as ESXi
emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09
ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't
defined until the SCSCI-3 spec. It's frustrating that the only way to
get the scsci_da code to call reprobe() is by receiving a command
from the device. Would something like this work? ...

1) Register a callback using xpt_register_async( daasync,
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async(
AC_REPROBE_DEVICE, path ) as a result

This way users would have the option of manually asking cam to
communicate the new size to geom. The only option now is one or more
reboots to gain access to the increased disk capacity. If this sounds
like a reasonable approach, I'll take a stab at implementing it.



Here is a proof of concept patch. I'm a complete noob when it comes to
cam, scsi or freebsd kernel development for that matter, so I'm sure
it could have been done a better way. In any case, I added a new
command to camcontrol that allows you to specify a bus, target and lun
as an argument. For example ...

# camcontrol readcap da1 -h
Device Size: 32 G, Block Length: 512 bytes

# gpart show da1
=>  40  58720176  da1  GPT  (28G)
40  587201761  freebsd-ufs  (28G)

Note, I resized the VMDK disk in ESXi. The camcontrol output shows the
size as 32G but geom thinks its 28G.

# camcontrol devlist
   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)

# camcontrol reprobe 2:1:0

This generates an event that is captured by the scsci da device to
forces a reprobe. The kernel output looks almost identical to when the
'Unit Attention' sense data is received ...

Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes
or `gpart undo da1` to revert them.

Now that geom knows about the increased disk capacity, I can increase
the partition size and grow the fs ...

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  67108784  da1  GPT  (32G)
40  587201761  freebsd-ufs  (28G)
  58720216   8388608   - free -  (4.0G)

# gpart resize -i 1 da1
da1p1 resized

# growfs da1p1
Device is mounted read-write; resizing will result in temporary write
suspension for /var/data1.
It's strongly recommended to make a backup before growing the file
system.
OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB
to 32GB? [Yes/No] Yes
super-block backups (for fsck_ffs -b #) at:
 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672

# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 18G5.3G 12G31%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p1 31G 32M 28G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

Sure would be nice to have something like this in the tree. It's
really a drag to have to reboot production VMs to increase disk
capacity when it could be easily avoided. I'm not sure what the
correct IOCTL should look like. Maybe CAMIOCOMMAND is a better way to
go? If someone with some experience with the cam/scsi subsystems was
willing to give me some direction I'd be willing to try and rewrite
the patch in a way that would be commit worthy. I just need some
direction.



Ok, last post until I get some feedback. Here's a new version of the
patch complete with man page updates. It communicates via CAMIOCOMMAND
instead of introducing a new ioctl value. I tried to model it after the
device reset option, hopefully with some degree of success. Functionally
it should be the same as the first patch.



The PR 204901 filed for this can be closed now that the author (ahem) 
has committed support for the camcontrol reprobe command ...


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204901
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=866020+0+current/svn-src-head

-Matthew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

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 Attention' sense information in 
response to a 'Read Capacity' request. This kinda makes sense as ESXi 
emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 
ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't 
defined until the SCSCI-3 spec. It's frustrating that the only way to 
get the scsci_da code to call reprobe() is by receiving a command from 
the device. Would something like this work? ...


1) Register a callback using xpt_register_async( daasync, 
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the 
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async( 
AC_REPROBE_DEVICE, path ) as a result


This way users would have the option of manually asking cam to 
communicate the new size to geom. The only option now is one or more 
reboots to gain access to the increased disk capacity. If this sounds 
like a reasonable approach, I'll take a stab at implementing it.




Here is a proof of concept patch. I'm a complete noob when it comes to 
cam, scsi or freebsd kernel development for that matter, so I'm sure it 
could have been done a better way. In any case, I added a new command to 
camcontrol that allows you to specify a bus, target and lun as an 
argument. For example ...


# camcontrol readcap da1 -h
Device Size: 32 G, Block Length: 512 bytes

# gpart show da1
=>  40  58720176  da1  GPT  (28G)
40  587201761  freebsd-ufs  (28G)

Note, I resized the VMDK disk in ESXi. The camcontrol output shows the 
size as 32G but geom thinks its 28G.


# camcontrol devlist
   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)

# camcontrol reprobe 2:1:0

This generates an event that is captured by the scsci da device to 
forces a reprobe. The kernel output looks almost identical to when the 
'Unit Attention' sense data is received ...


Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes 
or `gpart undo da1` to revert them.


Now that geom knows about the increased disk capacity, I can increase 
the partition size and grow the fs ...


[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  67108784  da1  GPT  (32G)
40  587201761  freebsd-ufs  (28G)
  58720216   8388608   - free -  (4.0G)

# gpart resize -i 1 da1
da1p1 resized

# growfs da1p1
Device is mounted read-write; resizing will result in temporary write 
suspension for /var/data1.

It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB to 
32GB? [Yes/No] Yes

super-block backups (for fsck_ffs -b #) at:
 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672

# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 18G5.3G 12G31%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p1 31G 32M 28G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

Sure would be nice to have something like this in the tree. It's really 
a drag to have to reboot production VMs to increase disk capacity when 
it could be easily avoided. I'm not sure what the correct IOCTL should 
look like. Maybe CAMIOCOMMAND is a better way to go? If someone with 
some experience with the cam/scsi subsystems was willing to give me some 
direction I'd be willing to try and rewrite the patch in a way that 
would be commit worthy. I just need some direction.


Thanks,

-Matthew
Index: lib/libcam/camlib.c
===
--- lib/libcam/camlib.c (revision 291390)
+++ lib/libcam/camlib.c (working copy)
@@ -752,3 +752,41 @@
bcopy(src, dst, sizeof(struct cam_device));
 
 }
+
+/*
+ * Send a reprobe unit request for a given bus, target and lun
+ */
+int
+cam_reprobe_btl(path_id_t path_id, target_id_t target_id, lun_id_t target_lun)
+{
+   int fd;
+   char *func_name = "cam_reprobe_btl";
+   union ccb ccb;
+
+   if ((fd = open(XPT_DEVICE, O_RDWR)) < 0) {
+   snprintf(cam_errbuf, CAM_ERRBUF_SIZE,
+"%s: couldn't open %s\n%s: %s", func_name, XPT_DEVICE,
+func_name, strerror(errno));
+   return(-1);
+   }
+
+   /* Setup our request ccb */
+   bzero(_h, sizeof(struct ccb_hdr));
+   ccb.ccb_h.path_id = path_id;
+   

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

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 
that ESXi doesn't return any 'Unit Attention' sense information in 
response to a 'Read Capacity' request. This kinda makes sense as ESXi 
emulates SCSI-2 disk devices and, as far as I can tell, the 0x2A/0x09 
ASC/ASCQ sense code that denotes 'Capacity Data Has Changed' wasn't 
defined until the SCSCI-3 spec. It's frustrating that the only way to 
get the scsci_da code to call reprobe() is by receiving a command 
from the device. Would something like this work? ...


1) Register a callback using xpt_register_async( daasync, 
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the 
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async( 
AC_REPROBE_DEVICE, path ) as a result


This way users would have the option of manually asking cam to 
communicate the new size to geom. The only option now is one or more 
reboots to gain access to the increased disk capacity. If this sounds 
like a reasonable approach, I'll take a stab at implementing it.




Here is a proof of concept patch. I'm a complete noob when it comes to 
cam, scsi or freebsd kernel development for that matter, so I'm sure 
it could have been done a better way. In any case, I added a new 
command to camcontrol that allows you to specify a bus, target and lun 
as an argument. For example ...


# camcontrol readcap da1 -h
Device Size: 32 G, Block Length: 512 bytes

# gpart show da1
=>  40  58720176  da1  GPT  (28G)
40  587201761  freebsd-ufs  (28G)

Note, I resized the VMDK disk in ESXi. The camcontrol output shows the 
size as 32G but geom thinks its 28G.


# camcontrol devlist
   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)

# camcontrol reprobe 2:1:0

This generates an event that is captured by the scsci da device to 
forces a reprobe. The kernel output looks almost identical to when the 
'Unit Attention' sense data is received ...


Nov 28 17:46:13 iscsi-i kernel: (da1:mpt0:0:1:0): Re-probe requested
Nov 28 17:46:13 iscsi-i kernel: GEOM_PART: da1 was automatically resized.
Nov 28 17:46:13 iscsi-i kernel: Use `gpart commit da1` to save changes 
or `gpart undo da1` to revert them.


Now that geom knows about the increased disk capacity, I can increase 
the partition size and grow the fs ...


[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  67108784  da1  GPT  (32G)
40  587201761  freebsd-ufs  (28G)
  58720216   8388608   - free -  (4.0G)

# gpart resize -i 1 da1
da1p1 resized

# growfs da1p1
Device is mounted read-write; resizing will result in temporary write 
suspension for /var/data1.
It's strongly recommended to make a backup before growing the file 
system.
OK to grow filesystem on /dev/da1p1, mounted on /var/data1, from 28GB 
to 32GB? [Yes/No] Yes

super-block backups (for fsck_ffs -b #) at:
 58983232, 60265472, 61547712, 62829952, 64112192, 65394432, 66676672

# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 18G5.3G 12G31%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p1 31G 32M 28G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

Sure would be nice to have something like this in the tree. It's 
really a drag to have to reboot production VMs to increase disk 
capacity when it could be easily avoided. I'm not sure what the 
correct IOCTL should look like. Maybe CAMIOCOMMAND is a better way to 
go? If someone with some experience with the cam/scsi subsystems was 
willing to give me some direction I'd be willing to try and rewrite 
the patch in a way that would be commit worthy. I just need some 
direction.




Ok, last post until I get some feedback. Here's a new version of the 
patch complete with man page updates. It communicates via CAMIOCOMMAND 
instead of introducing a new ioctl value. I tried to model it after the 
device reset option, hopefully with some degree of success. Functionally 
it should be the same as the first patch.


Thanks,

-Matthew
Index: sbin/camcontrol/camcontrol.8
===
--- sbin/camcontrol/camcontrol.8(revision 291390)
+++ sbin/camcontrol/camcontrol.8(working copy)
@@ -104,6 +104,9 @@
 .Ic reset
 .Aq all | bus Ns Op :target:lun
 .Nm
+.Ic reprobe
+.Aq bus:target:lun
+.Nm
 .Ic defects
 .Op device id
 .Op generic args
@@ -548,6 +551,9 @@
 connecting to that device.
 Note that this can have a destructive impact
 on the system.
+.It Ic reprobe
+Tell the kernel to re-probe the given 

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 11/27/2015 12:08 PM, Matthew Grooms wrote:

On 11/27/2015 3:16 AM, Willem Jan Withagen wrote:

On 27-11-2015 06:59, Matthew Grooms wrote:

All,

I know this is a very late follow up, but spent some more time looking
at this today and found some additional information that I found quite
interesting. I setup two VMs, one that acts as an iSCSI initiator (
CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are
running under ESXi v5.5. There are two block devices on the initiator,
da1 and da2, that I used for resize testing ...

[root@iscsi-i /home/mgrooms]# camcontrol devlist
   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]# pciconf
...
mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000
rev=0x01 hdr=0x00
 vendor = 'LSI Logic / Symbios Logic'
 device = 'SAS1068 PCI-X Fusion-MPT SAS'
 class  = mass storage
 subclass   = SAS

[root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  20971440  da1  GPT  (10G)
 40  209714401  freebsd-ufs  (10G)

The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running
ctld ...

[root@iscsi-i /home/mgrooms]# iscsictl
Target name  Target portalState
iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2

[root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da2
=>  40  20971440  da2  GPT  (10G)
 4024   - free -  (12K)
 64  209713921  freebsd-ufs  (10G)
   2097145624   - free -  (12K)

When I increased the size of da1 ( the VMDK ) and then re-ran
'camcontrol readcap' without a reboot, it clearly showed that the disk
size had increased. However, geom failed to recognize the additional
capacity ...

[root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h
Device Size: 16 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  20971440  da1  GPT  (10G)
 40  209714401  freebsd-ufs  (10G)

Here is the interesting bit. I increased the size of da2 by modifying
the lun size in ctld.conf on the target and then issued a 
/etc/rd.d/ctld

reload. When I re-ran 'camcontrol readcap' on the initiator without a
reboot, it also showed that the disk size had increased, but this time
geom recognized the additional capacity as well ...

[root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h
Device Size: 16 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da2
=>  40  33554352  da2  GPT  (16G)
 4024   - free -  (12K)
 64  209713921  freebsd-ufs  (10G)
   20971456  12582936   - free -  (6.0G)

I was then able to resize the partition and then grow the UFS
filesystem, all without rebooting the VM ...

[root@iscsi-i /home/mgrooms]# gpart resize -i 1 da2
da2p1 resized

[root@iscsi-i /home/mgrooms]# gpart show da2
=>  40  33554352  da2  GPT  (16G)
 4024   - free -  (12K)
 64  335543041  freebsd-ufs  (16G)
   3355436824   - free -  (12K)

[root@iscsi-i /home/mgrooms]# growfs da2p1
Device is mounted read-write; resizing will result in temporary write
suspension for /var/data2.
It's strongly recommended to make a backup before growing the file 
system.
OK to grow filesystem on /dev/da2p1, mounted on /var/data2, from 
10GB to

16GB? [Yes/No] Yes
super-block backups (for fsck_ffs -b #) at:
  21798272, 23080512, 24362752, 25644992, 26927232, 28209472, 29491712,
30773952, 32056192, 8432

[root@iscsi-i /home/mgrooms]# df -h
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/da0p3 15G1.2G 12G 9%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p19.7G 32M8.9G 0%/var/data1
/dev/da2p1 15G 32M 14G 0%/var/data2

It's also worth noting that the additional space was not recognized by
gpart/geom on the initiator until after the 'camcontrol readcap da2'
command was run. In other words, I'm skeptical that it was a Unit
Attention notification that made the right thing happen since it still
took manual prodding of cam to get the new disk geometry up into the
geom layer.


I remember doing this for a bhyve VM, and had the type same problem.
Getting gpart in the VM to actually pickup the new size required some
extra prodding (I like that word) or rebooting the VM.
I can remember reporting this:
tpoic: "resampeling of a ZVOL that has been resized"
and getting a fix from Andrey V. Elsukov...

Index: head/s

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 11/27/2015 3:16 AM, Willem Jan Withagen wrote:

On 27-11-2015 06:59, Matthew Grooms wrote:

On 10/16/2014 3:10 AM, Edward Tomasz Napierała wrote:

On 1010T1529, Matthew Grooms wrote:

All,

I am a long time user and advocate of FreeBSD and manage a several
deployments of FreeBSD in a few data centers. Now that these
environments are almost always virtual, it would make sense that 
FreeBSD
support for basic features such as dynamic disk resizing. It looks 
like
most of the parts are intended to work. Kudos to the FreeBSD 
foundation

for seeing the need and sponsoring dynamic increase 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 using ZFS, 
I see

the following ...

root@zpool-test:~ #  gpart show
=>  34  16777149  da0  GPT  (8.0G)
  34  10241  freebsd-boot  (512K)
1058   41943042  freebsd-swap  (2.0G)
 4195362  125818213  freebsd-zfs  (6.0G)

If I increase the VM disk size using VMware to 16G and rescan using
camcontrol, this is what I see ...

"camcontrol rescan" does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the "other side" properly sends proper Unit Attention
after resizing.  No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.

[..]


Now I want the claim the additional 14 gigs of space for my zpool ...

root@zpool-test:~ # zpool status
pool: zroot
   state: ONLINE
scan: none requested
config:

  NAME STATE READ
WRITE CKSUM
  zroot ONLINE 0
0 0
gptid/352086bd-50b5-11e4-95b8-0050569b2a04 ONLINE 0
0 0

root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  5.97G   876M  5.11G14%  1.00x  ONLINE  -

The zpool appears to still only have 5.11G free. Lets reboot and try
again ...
Interesting.  This used to work; actually either of those 
(autoexpand or

online -e) should do the trick.


root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  14.0G   876M  13.1G 6%  1.00x  ONLINE  -

Now I have 13.1G free. I can add this space to any of my zfs 
volumes and

it picks the change up immediately. So the question remains, why do I
need to reboot the OS twice to allocate new disk space to a volume?
FreeBSD is first and foremost a server operating system. Servers are
commonly deployed in data centers. Virtual environments are now
commonplace in data centers, not the exception to the rule. VMware 
still

has the vast majority of the private virutal environment market. I
assume that most would expect things like this to work out of the box.
Did I miss a required step or is this fixed in CURRENT?

Looks like genuine bugs (or rather, one missing feature and one bug).
Filling PRs for those might be a good idea.



All,

I know this is a very late follow up, but spent some more time looking
at this today and found some additional information that I found quite
interesting. I setup two VMs, one that acts as an iSCSI initiator (
CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are
running under ESXi v5.5. There are two block devices on the initiator,
da1 and da2, that I used for resize testing ...

[root@iscsi-i /home/mgrooms]# camcontrol devlist
   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]# pciconf
...
mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000
rev=0x01 hdr=0x00
 vendor = 'LSI Logic / Symbios Logic'
 device = 'SAS1068 PCI-X Fusion-MPT SAS'
 class  = mass storage
 subclass   = SAS

[root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  20971440  da1  GPT  (10G)
 40  209714401  freebsd-ufs  (10G)

The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running
ctld ...

[root@iscsi-i /home/mgrooms]# iscsictl
Target name  Target portalState
iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2

[root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /hom

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 11/27/2015 12:56 PM, Matthew Grooms wrote:
I thought it would be useful to get more output from the geom layer, 
similar to the camcontrol debug output ...


[root@iscsi-i /home/mgrooms]# sysctl kern.geom.debugflags=0x81

When I resize the iSCSI LUN and run the 'camcontrol readcap da2 -h', I 
see this in the log output ...


[root@iscsi-i /home/mgrooms]# tail -f /var/log/messages
...
Nov 27 12:20:07 iscsi-i kernel: (pass3:iscsi1:0:0:0): Capacity data 
has changed
Nov 27 12:20:07 iscsi-i kernel: g_post_event_x(0x80973850, 
0xf80003f4e000, 1, 0)
Nov 27 12:20:07 iscsi-i kernel: g_post_event_x(0x8097a6b0, 
0xf80003f42b60, 2, 0)
Nov 27 12:20:07 iscsi-i kernel: 
g_resize_provider_event(0xf800038c6700)

Nov 27 12:20:07 iscsi-i kernel: g_part_resize(da2)
Nov 27 12:20:07 iscsi-i kernel: GEOM_PART: da2 was automatically resized.
Nov 27 12:20:07 iscsi-i kernel: Use `gpart commit da2` to save changes 
or `gpart undo da2` to revert them.

Nov 27 12:20:07 iscsi-i kernel: g_raid_taste(RAID, da2)
Nov 27 12:20:07 iscsi-i kernel: g_attach(0xf80003e64780, 
0xf800038c6700)

Nov 27 12:20:07 iscsi-i kernel: g_detach(0xf80003e64780)
Nov 27 12:20:07 iscsi-i kernel: g_destroy_consumer(0xf80003e64780)
Nov 27 12:20:07 iscsi-i kernel: 
g_destroy_geom(0xf800038c9c00(raid:taste))

Nov 27 12:20:07 iscsi-i kernel: g_label_taste(LABEL, da2)

However, when I resize the VMDK disk and run the 'camcontrol readcap 
da1 -h' command, I see nothing in the log 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?


I'm not sure if this is useful but here is what the device info looks 
like at boot time ...


mpt0:  port 0x4000-0x40ff mem 
0xfd4ec000-0xfd4e,0xfd4f-0xfd4f irq 18 at device 0.0 on pci3

mpt0: MPI Version=1.5.0.0
...
da0 at mpt0 bus 0 scbus2 target 0 lun 0
da0:  Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 20480MB (41943040 512 byte sectors)
da0: quirks=0x40
da1 at mpt0 bus 0 scbus2 target 1 lun 0
da1:  Fixed Direct Access SCSI-2 device
da1: 300.000MB/s transfers
da1: Command Queueing enabled
da1: 20480MB (41943040 512 byte sectors)
da1: quirks=0x40
...
da2 at iscsi1 bus 0 scbus3 target 0 lun 0
da2:  Fixed Direct Access SPC-4 SCSI device
da2: Serial Number MYSERIAL   0
da2: 150.000MB/s transfers
da2: Command Queueing enabled
da2: 16384MB (33554432 512 byte sectors)



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 Attention' sense information in response to a 
'Read Capacity' request. This kinda makes sense as ESXi emulates SCSI-2 
disk devices and, as far as I can tell, the 0x2A/0x09 ASC/ASCQ sense 
code that denotes 'Capacity Data Has Changed' wasn't defined until the 
SCSCI-3 spec. It's frustrating that the only way to get the scsci_da 
code to call reprobe() is by receiving a command from the device. Would 
something like this work? ...


1) Register a callback using xpt_register_async( daasync, 
AC_REPROBE_DEVICE, path ) that calls reprobe()
2) Implement a new IOCTL in cam_xpt that camcontrol can call with the 
bus:target:lun as the argument
3) have cam_xpt capture the IOCTL request and call xpt_async( 
AC_REPROBE_DEVICE, path ) as a result


This way users would have the option of manually asking cam to 
communicate the new size to geom. The only option now is one or more 
reboots to gain access to the increased disk capacity. If this sounds 
like a reasonable approach, I'll take a stab at implementing it.


Thanks,

-Matthew
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Resizing a zpool as a VMware ESXi guest ...

[Willem Jan Withagen]

On 27-11-2015 06:59, Matthew Grooms wrote:

On 10/16/2014 3:10 AM, Edward Tomasz Napierała wrote:

On 1010T1529, Matthew Grooms wrote:

All,

I am a long time user and advocate of FreeBSD and manage a several
deployments of FreeBSD in a few data centers. Now that these
environments are almost always virtual, it would make sense that FreeBSD
support for basic features such as dynamic disk resizing. It looks like
most of the parts are intended to work. Kudos to the FreeBSD foundation
for seeing the need and sponsoring dynamic increase 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 using ZFS, I see
the following ...

root@zpool-test:~ #  gpart show
=>  34  16777149  da0  GPT  (8.0G)
  34  10241  freebsd-boot  (512K)
1058   41943042  freebsd-swap  (2.0G)
 4195362  125818213  freebsd-zfs  (6.0G)

If I increase the VM disk size using VMware to 16G and rescan using
camcontrol, this is what I see ...

"camcontrol rescan" does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the "other side" properly sends proper Unit Attention
after resizing.  No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.

[..]


Now I want the claim the additional 14 gigs of space for my zpool ...

root@zpool-test:~ # zpool status
pool: zroot
   state: ONLINE
scan: none requested
config:

  NAME  STATE READ
WRITE CKSUM
  zroot ONLINE 0
0 0
gptid/352086bd-50b5-11e4-95b8-0050569b2a04  ONLINE 0
0 0

root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  5.97G   876M  5.11G14%  1.00x  ONLINE  -

The zpool appears to still only have 5.11G free. Lets reboot and try
again ...

Interesting.  This used to work; actually either of those (autoexpand or
online -e) should do the trick.


root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  14.0G   876M  13.1G 6%  1.00x  ONLINE  -

Now I have 13.1G free. I can add this space to any of my zfs volumes and
it picks the change up immediately. So the question remains, why do I
need to reboot the OS twice to allocate new disk space to a volume?
FreeBSD is first and foremost a server operating system. Servers are
commonly deployed in data centers. Virtual environments are now
commonplace in data centers, not the exception to the rule. VMware still
has the vast majority of the private virutal environment market. I
assume that most would expect things like this to work out of the box.
Did I miss a required step or is this fixed in CURRENT?

Looks like genuine bugs (or rather, one missing feature and one bug).
Filling PRs for those might be a good idea.



All,

I know this is a very late follow up, but spent some more time looking
at this today and found some additional information that I found quite
interesting. I setup two VMs, one that acts as an iSCSI initiator (
CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are
running under ESXi v5.5. There are two block devices on the initiator,
da1 and da2, that I used for resize testing ...

[root@iscsi-i /home/mgrooms]# camcontrol devlist
   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]# pciconf
...
mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000
rev=0x01 hdr=0x00
 vendor = 'LSI Logic / Symbios Logic'
 device = 'SAS1068 PCI-X Fusion-MPT SAS'
 class  = mass storage
 subclass   = SAS

[root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  20971440  da1  GPT  (10G)
 40  209714401  freebsd-ufs  (10G)

The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running
ctld ...

[root@iscsi-i /home/mgrooms]# iscsictl
Target name  Target portalState
iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2

[root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h
Device Size: 10 G, Block Length: 512 bytes

[

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 10/16/2014 3:10 AM, Edward Tomasz Napierała wrote:

On 1010T1529, Matthew Grooms wrote:

All,

I am a long time user and advocate of FreeBSD and manage a several
deployments of FreeBSD in a few data centers. Now that these
environments are almost always virtual, it would make sense that FreeBSD
support for basic features such as dynamic disk resizing. It looks like
most of the parts are intended to work. Kudos to the FreeBSD foundation
for seeing the need and sponsoring dynamic increase 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 using ZFS, I see
the following ...

root@zpool-test:~ #  gpart show
=>  34  16777149  da0  GPT  (8.0G)
  34  10241  freebsd-boot  (512K)
1058   41943042  freebsd-swap  (2.0G)
 4195362  125818213  freebsd-zfs  (6.0G)

If I increase the VM disk size using VMware to 16G and rescan using
camcontrol, this is what I see ...

"camcontrol rescan" does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the "other side" properly sends proper Unit Attention
after resizing.  No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.

[..]


Now I want the claim the additional 14 gigs of space for my zpool ...

root@zpool-test:~ # zpool status
pool: zroot
   state: ONLINE
scan: none requested
config:

  NAME  STATE READ
WRITE CKSUM
  zroot ONLINE 0 0 0
gptid/352086bd-50b5-11e4-95b8-0050569b2a04  ONLINE 0 0 0

root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  5.97G   876M  5.11G14%  1.00x  ONLINE  -

The zpool appears to still only have 5.11G free. Lets reboot and try
again ...

Interesting.  This used to work; actually either of those (autoexpand or
online -e) should do the trick.


root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot
gptid/352086bd-50b5-11e4-95b8-0050569b2a04
root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  14.0G   876M  13.1G 6%  1.00x  ONLINE  -

Now I have 13.1G free. I can add this space to any of my zfs volumes and
it picks the change up immediately. So the question remains, why do I
need to reboot the OS twice to allocate new disk space to a volume?
FreeBSD is first and foremost a server operating system. Servers are
commonly deployed in data centers. Virtual environments are now
commonplace in data centers, not the exception to the rule. VMware still
has the vast majority of the private virutal environment market. I
assume that most would expect things like this to work out of the box.
Did I miss a required step or is this fixed in CURRENT?

Looks like genuine bugs (or rather, one missing feature and one bug).
Filling PRs for those might be a good idea.



All,

I know this is a very late follow up, but spent some more time looking 
at this today and found some additional information that I found quite 
interesting. I setup two VMs, one that acts as an iSCSI initiator ( 
CURRENT ) and another that acts as a target ( 10.2-RELEASE ). Both are 
running under ESXi v5.5. There are two block devices on the initiator, 
da1 and da2, that I used for resize testing ...


[root@iscsi-i /home/mgrooms]# camcontrol devlist
   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]# pciconf
...
mpt0@pci0:3:0:0:class=0x010700 card=0x197615ad chip=0x00541000 
rev=0x01 hdr=0x00

vendor = 'LSI Logic / Symbios Logic'
device = 'SAS1068 PCI-X Fusion-MPT SAS'
class  = mass storage
subclass   = SAS

[root@iscsi-i /home/mgrooms]# camcontrol readcap da1 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]# gpart show da1
=>  40  20971440  da1  GPT  (10G)
40  209714401  freebsd-ufs  (10G)

The da2 device is an iSCSI LUN mounted from my FreeBSD 10.2 VM running 
ctld ...


[root@iscsi-i /home/mgrooms]# iscsictl
Target name  Target portalState
iqn.2015-01.lab.shrew:target0iscsi-t.shrew.lab Connected: da2

[root@iscsi-i /home/mgrooms]# camcontrol readcap da2 -h
Device Size: 10 G, Block Length: 512 bytes

[root@iscsi-i /home/mgrooms]#

Re: Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

On 10/16/2014 3:17 AM, Garrett Cooper wrote:



On Oct 16, 2014, at 1:10, Edward Tomasz Napierała
tr...@freebsd.org wrote:



camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the other side properly 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.



VMware tools were not installed at the time. I'll try that, but I doubt 
it will make a difference for resizing.



Also, what disk controller are you using?



The ESXi 5.5 default controller for FreeBSD, LSI Logic Parallel ...

mpt0@pci0:0:16:0:	class=0x01 card=0x197615ad chip=0x00301000 
rev=0x01 hdr=0x00

vendor = 'LSI Logic / Symbios Logic'
device = '53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI'
class  = mass storage
subclass   = SCSI

I'll try it with the LSI Logic SAS controller as well to see if that 
makes a difference.


-Matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Resizing a zpool as a VMware ESXi guest ...

[Edward Tomasz Napierała]

On 1010T1529, Matthew Grooms wrote:
 All,
 
 I am a long time user and advocate of FreeBSD and manage a several 
 deployments of FreeBSD in a few data centers. Now that these 
 environments are almost always virtual, it would make sense that FreeBSD 
 support for basic features such as dynamic disk resizing. It looks like 
 most of the parts are intended to work. Kudos to the FreeBSD foundation 
 for seeing the need and sponsoring dynamic increase 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 using ZFS, I see 
 the following ...
 
 root@zpool-test:~ #  gpart show
 =  34  16777149  da0  GPT  (8.0G)
  34  10241  freebsd-boot  (512K)
1058   41943042  freebsd-swap  (2.0G)
 4195362  125818213  freebsd-zfs  (6.0G)
 
 If I increase the VM disk size using VMware to 16G and rescan using 
 camcontrol, this is what I see ...

camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the other side properly sends proper Unit Attention
after resizing.  No idea why this doesn't happen with VMWare.
Reboot obviously clears things up.

[..]

 Now I want the claim the additional 14 gigs of space for my zpool ...
 
 root@zpool-test:~ # zpool status
pool: zroot
   state: ONLINE
scan: none requested
 config:
 
  NAME  STATE READ 
 WRITE CKSUM
  zroot ONLINE 0 0 0
gptid/352086bd-50b5-11e4-95b8-0050569b2a04  ONLINE 0 0 0
 
 root@zpool-test:~ # zpool set autoexpand=on zroot
 root@zpool-test:~ # zpool online -e zroot 
 gptid/352086bd-50b5-11e4-95b8-0050569b2a04
 root@zpool-test:~ # zpool list
 NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
 zroot  5.97G   876M  5.11G14%  1.00x  ONLINE  -
 
 The zpool appears to still only have 5.11G free. Lets reboot and try 
 again ...

Interesting.  This used to work; actually either of those (autoexpand or
online -e) should do the trick.

 root@zpool-test:~ # zpool set autoexpand=on zroot
 root@zpool-test:~ # zpool online -e zroot 
 gptid/352086bd-50b5-11e4-95b8-0050569b2a04
 root@zpool-test:~ # zpool list
 NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
 zroot  14.0G   876M  13.1G 6%  1.00x  ONLINE  -
 
 Now I have 13.1G free. I can add this space to any of my zfs volumes and 
 it picks the change up immediately. So the question remains, why do I 
 need to reboot the OS twice to allocate new disk space to a volume? 
 FreeBSD is first and foremost a server operating system. Servers are 
 commonly deployed in data centers. Virtual environments are now 
 commonplace in data centers, not the exception to the rule. VMware still 
 has the vast majority of the private virutal environment market. I 
 assume that most would expect things like this to work out of the box. 
 Did I miss a required step or is this fixed in CURRENT?

Looks like genuine bugs (or rather, one missing feature and one bug).
Filling PRs for those might be a good idea.

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Resizing a zpool as a VMware ESXi guest ...

[Garrett Cooper]

 On Oct 16, 2014, at 1:10, Edward Tomasz Napierała tr...@freebsd.org wrote:

 camcontrol rescan does not force fetching the updated disk size.
 AFAIK there is no way to do that.  However, this should happen
 automatically, if the other side properly 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.

Also, what disk controller are you using?

Cheers.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Resizing a zpool as a VMware ESXi guest ...

[Michael Jung]

On 2014-10-16 04:17, Garrett Cooper wrote:
On Oct 16, 2014, at 1:10, Edward Tomasz Napierała tr...@freebsd.org 
wrote:



camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that.  However, this should happen
automatically, if the other side properly 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.

Also, what disk controller are you using?

Cheers.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
freebsd-current-unsubscr...@freebsd.org


I duplicated this behavior.  According to gpart The virtual disk does 
not grow

until the freebsd guest is rebooted.

FreeBSD freebsd10 10.0-RELEASE-p6 FreeBSD 10.0-RELEASE-p6 #0: Tue Jun 24 
07:47:37 UTC 2014

r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC

pkg info -- amd64 open-vm-tools-nox11-1280544_8,1 Open VMware tools for 
FreeBSD VMware guests

ESXi reported -- Running, version:2147483647 (3rd-party/Independent)

ESXi-5.5-1331820(A00) Guest Hardware version 10

789  -  S 0:00.54 /usr/local/bin/vmtoolsd -c 
/usr/local/share/vmware-tools/


Id Refs AddressSize Name

1   12 0x8020 15f03b0  kernel
21 0x81a12000 5209 fdescfs.ko
31 0x81a18000 2198 vmmemctl.ko
41 0x81a1b000 23d8 vmxnet.ko
51 0x81a1e000 2bf0 vmblock.ko
61 0x81a21000 81b4 vmhgfs.ko

--mikej
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Resizing a zpool as a VMware ESXi guest ...

[Matthew Grooms]

All,

I am a long time user and advocate of FreeBSD and manage a several 
deployments of FreeBSD in a few data centers. Now that these 
environments are almost always virtual, it would make sense that FreeBSD 
support for basic features such as dynamic disk resizing. It looks like 
most of the parts are intended to work. Kudos to the FreeBSD foundation 
for seeing the need and sponsoring dynamic increase 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 using ZFS, I see 
the following ...


root@zpool-test:~ #  gpart show
=  34  16777149  da0  GPT  (8.0G)
34  10241  freebsd-boot  (512K)
  1058   41943042  freebsd-swap  (2.0G)
   4195362  125818213  freebsd-zfs  (6.0G)

If I increase the VM disk size using VMware to 16G and rescan using 
camcontrol, this is what I see ...


root@zpool-test:~ # camcontrol rescan all
Re-scan of bus 0 was successful
Re-scan of bus 1 was successful
Re-scan of bus 2 was successful
root@zpool-test:~ # gpart show
=  34  16777149  da0  GPT  (8.0G)
34  10241  freebsd-boot  (512K)
  1058   41943042  freebsd-swap  (2.0G)
   4195362  125818213  freebsd-zfs  (6.0G)

The GPT label still appears to be 8G. If I reboot the VM, it picks up 
the correct size ...


root@zpool-test:~ # gpart show
=  34  16777149  da0  GPT  (16G) [CORRUPT]
34  10241  freebsd-boot  (512K)
  1058   41943042  freebsd-swap  (2.0G)
   4195362  125818213  freebsd-zfs  (6.0G)

Now I have 16G to play with. I'll expand the freebsd-zfs partition to 
claim the additional space ...


root@zpool-test:~ # gpart recover da0
da0 recovered

root@zpool-test:~ # gpart show
=  34  33554365  da0  GPT  (16G)
34  10241  freebsd-boot  (512K)
  1058   41943042  freebsd-swap  (2.0G)
   4195362  125818213  freebsd-zfs  (6.0G)
  16777183  16777216   - free -  (8.0G)

root@zpool-test:~ # gpart resize -i 3 da0

root@zpool-test:~ # gpart show
=  34  33554365  da0  GPT  (16G)
34  10241  freebsd-boot  (512K)
  1058   41943042  freebsd-swap  (2.0G)
   4195362  293590373  freebsd-zfs  (14G)

Now I want the claim the additional 14 gigs of space for my zpool ...

root@zpool-test:~ # zpool status
  pool: zroot
 state: ONLINE
  scan: none requested
config:

NAME  STATE READ 
WRITE CKSUM

zroot ONLINE 0 0 0
  gptid/352086bd-50b5-11e4-95b8-0050569b2a04  ONLINE 0 0 0

root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot 
gptid/352086bd-50b5-11e4-95b8-0050569b2a04

root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  5.97G   876M  5.11G14%  1.00x  ONLINE  -

The zpool appears to still only have 5.11G free. Lets reboot and try 
again ...


root@zpool-test:~ # zpool set autoexpand=on zroot
root@zpool-test:~ # zpool online -e zroot 
gptid/352086bd-50b5-11e4-95b8-0050569b2a04

root@zpool-test:~ # zpool list
NAMESIZE  ALLOC   FREECAP  DEDUP  HEALTH  ALTROOT
zroot  14.0G   876M  13.1G 6%  1.00x  ONLINE  -

Now I have 13.1G free. I can add this space to any of my zfs volumes and 
it picks the change up immediately. So the question remains, why do I 
need to reboot the OS twice to allocate new disk space to a volume? 
FreeBSD is first and foremost a server operating system. Servers are 
commonly deployed in data centers. Virtual environments are now 
commonplace in data centers, not the exception to the rule. VMware still 
has the vast majority of the private virutal environment market. I 
assume that most would expect things like this to work out of the box. 
Did I miss a required step or is this fixed in CURRENT?


Thanks,

-Matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- 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
 others do it in a taskqueue.
 
 BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can,
 but I bet the e1000e does.
 
  if_vmx - if_vmx
  1.32 GBits/sec, load: 10-45%Sys 40-48%Intr
  
  if_vmxJumbo - if_vmxJumbo
  5.01 GBits/sec, load: 10-45%Sys 40-48%Intr
  
  Please find attached the different outputs of dev.vmx.X (the mtu9000 run
  was
  only 3.47GBits/sec in that case, took the numbers anyway)
  

Thanks for the sysctl output. 

dev.vmx.0.txq0.ringfull: 133479
dev.vmx.0.txq0.hstats.tso_packets: 564986
dev.vmx.0.txq0.hstats.ucast_packets: 570604

For the number of packets transmitted, there's a really high
percentage of time we find the Tx queue full enough it is not
able to hold the next to transmit frame. I've haven't been
able to recreate this. But I recently made a commit [1] that
might help alleviate this.

[1] http://svnweb.freebsd.org/base?view=revisionrevision=255055

  wbr,
  
  -Harry
  
  
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Harald Schmalzbauer]

 Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime):

...

 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 with vmxnet3.

 This could fail for two reasons - could not allocate an mbuf cluster,
 or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you
 should check vmstat -z. For the later, the behavior of 
 bus_dmamap_load_mbuf_sg()
 changed between 9.1 and 9.2, and I know it was broken for awhile. I don't
 recall exactly when I fixed it (I think shortly after I made the original
 announcement). Could you retry with the files from HEAD @ [1]? Also, there
 are new sysctl oids (dev.vmx.X.mbuf_load_failed  dev.vmx.X.mgetcl_failed)
 for these errors.

 I just compiled the driver on 9.2-RC2 with the sources from 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 host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
 5.1U1 and FreeBSD-9.2-RC2
 Two guests are connected to one MTU9000 VMware Software Switch.

 I've got a few performance things to still look at. What's the sysctl 
 dev.vmx.X output for the if_vmx-if_vmx tests?

Just repeated if_vmx simple iperf bench, results vary slightly from
standard 10sec run to run, but still noticable high Intr usage:

if_vmx - if_vmx
1.32 GBits/sec, load: 10-45%Sys 40-48%Intr

if_vmxJumbo - if_vmxJumbo
5.01 GBits/sec, load: 10-45%Sys 40-48%Intr

Please find attached the different outputs of dev.vmx.X (the mtu9000 run was 
only 3.47GBits/sec in that case, took the numbers anyway)

wbr,

-Harry

dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter
dev.vmx.0.%driver: vmx
dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0
dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad 
subdevice=0x07b0 class=0x02
dev.vmx.0.%parent: pci3
dev.vmx.0.ntxqueues: 1
dev.vmx.0.nrxqueues: 1
dev.vmx.0.collapsed: 0
dev.vmx.0.mgetcl_failed: 0
dev.vmx.0.mbuf_load_failed: 0
dev.vmx.0.txq0.ringfull: 133479
dev.vmx.0.txq0.offload_failed: 0
dev.vmx.0.txq0.hstats.tso_packets: 564986
dev.vmx.0.txq0.hstats.tso_bytes: 1686184580
dev.vmx.0.txq0.hstats.ucast_packets: 570604
dev.vmx.0.txq0.hstats.unicast_bytes: 1694679608
dev.vmx.0.txq0.hstats.mcast_packets: 0
dev.vmx.0.txq0.hstats.mcast_bytes: 0
dev.vmx.0.txq0.hstats.error: 0
dev.vmx.0.txq0.hstats.discard: 0
dev.vmx.0.txq0.debug.cmd_head: 106
dev.vmx.0.txq0.debug.cmd_next: 106
dev.vmx.0.txq0.debug.cmd_ndesc: 512
dev.vmx.0.txq0.debug.cmd_gen: 0
dev.vmx.0.txq0.debug.comp_next: 238
dev.vmx.0.txq0.debug.comp_ndesc: 512
dev.vmx.0.txq0.debug.comp_gen: 1
dev.vmx.0.rxq0.hstats.lro_packets: 0
dev.vmx.0.rxq0.hstats.lro_bytes: 0
dev.vmx.0.rxq0.hstats.ucast_packets: 579137
dev.vmx.0.rxq0.hstats.unicast_bytes: 38409312
dev.vmx.0.rxq0.hstats.mcast_packets: 0
dev.vmx.0.rxq0.hstats.mcast_bytes: 0
dev.vmx.0.rxq0.hstats.bcast_packets: 29
dev.vmx.0.rxq0.hstats.bcast_bytes: 1740
dev.vmx.0.rxq0.hstats.nobuffer: 0
dev.vmx.0.rxq0.hstats.error: 0
dev.vmx.0.rxq0.debug.cmd0_fill: 94
dev.vmx.0.rxq0.debug.cmd0_ndesc: 256
dev.vmx.0.rxq0.debug.cmd0_gen: 0
dev.vmx.0.rxq0.debug.cmd1_fill: 0
dev.vmx.0.rxq0.debug.cmd1_ndesc: 256
dev.vmx.0.rxq0.debug.cmd1_gen: 0
dev.vmx.0.rxq0.debug.comp_next: 94
dev.vmx.0.rxq0.debug.comp_ndesc: 512
dev.vmx.0.rxq0.debug.comp_gen: 0
dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter
dev.vmx.0.%driver: vmx
dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0
dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad 
subdevice=0x07b0 class=0x02
dev.vmx.0.%parent: pci3
dev.vmx.0.ntxqueues: 1
dev.vmx.0.nrxqueues: 1
dev.vmx.0.collapsed: 0
dev.vmx.0.mgetcl_failed: 0
dev.vmx.0.mbuf_load_failed: 0
dev.vmx.0.txq0.ringfull: 58950
dev.vmx.0.txq0.offload_failed: 0
dev.vmx.0.txq0.hstats.tso_packets: 230508
dev.vmx.0.txq0.hstats.tso_bytes: 4314020112
dev.vmx.0.txq0.hstats.ucast_packets: 235382
dev.vmx.0.txq0.hstats.unicast_bytes: 4356943552
dev.vmx.0.txq0.hstats.mcast_packets: 0
dev.vmx.0.txq0.hstats.mcast_bytes: 0
dev.vmx.0.txq0.hstats.error: 0
dev.vmx.0.txq0.hstats.discard: 0
dev.vmx.0.txq0.debug.cmd_head: 333
dev.vmx.0.txq0.debug.cmd_next: 333
dev.vmx.0.txq0.debug.cmd_ndesc: 512
dev.vmx.0.txq0.debug.cmd_gen: 0
dev.vmx.0.txq0.debug.comp_next: 376
dev.vmx.0.txq0.debug.comp_ndesc: 512
dev.vmx.0.txq0.debug.comp_gen: 0
dev.vmx.0.rxq0.hstats.lro_packets: 0
dev.vmx.0.rxq0.hstats.lro_bytes: 0
dev.vmx.0.rxq0.hstats.ucast_packets: 255918
dev.vmx.0.rxq0.hstats.unicast_bytes: 17043918
dev.vmx.0.rxq0.hstats.mcast_packets: 0
dev.vmx.0.rxq0.hstats.mcast_bytes: 0
dev.vmx.0.rxq0.hstats.bcast_packets: 15
dev.vmx.0.rxq0.hstats.bcast_bytes: 900
dev.vmx.0.rxq0.hstats.nobuffer: 0
dev.vmx.0.rxq0.hstats.error: 0
dev.vmx.0.rxq0.debug.cmd0_fill: 121
dev.vmx.0.rxq0

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- Original Message -
 Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime):
 
 ...
 
  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 with vmxnet3.
 
  This could fail for two reasons - could not allocate an mbuf cluster,
  or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you
  should check vmstat -z. For the later, the behavior of
  bus_dmamap_load_mbuf_sg()
  changed between 9.1 and 9.2, and I know it was broken for awhile. I don't
  recall exactly when I fixed it (I think shortly after I made the original
  announcement). Could you retry with the files from HEAD @ [1]? Also, there
  are new sysctl oids (dev.vmx.X.mbuf_load_failed  dev.vmx.X.mgetcl_failed)
  for these errors.
 
  I just compiled the driver on 9.2-RC2 with the sources from 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 host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
  5.1U1 and FreeBSD-9.2-RC2
  Two guests are connected to one MTU9000 VMware Software Switch.
 
  I've got a few performance things to still look at. What's the sysctl
  dev.vmx.X output for the if_vmx-if_vmx tests?
 
 Just repeated if_vmx simple iperf bench, results vary slightly from
 standard 10sec run to run, but still noticable high Intr usage:


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
others do it in a taskqueue.

BTW: if_vmx can to LRO as well. I don't think the emulated e1000 can,
but I bet the e1000e does.

 if_vmx - if_vmx
 1.32 GBits/sec, load: 10-45%Sys 40-48%Intr
 
 if_vmxJumbo - if_vmxJumbo
 5.01 GBits/sec, load: 10-45%Sys 40-48%Intr
 
 Please find attached the different outputs of dev.vmx.X (the mtu9000 run was
 only 3.47GBits/sec in that case, took the numbers anyway)
 
 wbr,
 
 -Harry
 
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- Original Message -
 Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime):
  Hi,
 
  I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
  lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
  the way so there is not much of a resemblance left.
 
  The driver is in good enough shape I'd like additional testers. A patch
  against -CURRENT is at [1]. 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. 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 with vmxnet3.
 

This could fail for two reasons - could not allocate an mbuf cluster,
or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you
should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg()
changed between 9.1 and 9.2, and I know it was broken for awhile. I don't
recall exactly when I fixed it (I think shortly after I made the original
announcement). Could you retry with the files from HEAD @ [1]? Also, there
are new sysctl oids (dev.vmx.X.mbuf_load_failed  dev.vmx.X.mgetcl_failed)
for these errors.

I just compiled the driver on 9.2-RC2 with the sources from HEAD and was
able to change the MTU to 9000.

[1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/

 I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
 5.1U1 and FreeBSD-9.2-RC2
 Two guests are connected to one MTU9000 VMware Software Switch.
 

I've got a few performance things to still look at. What's the sysctl 
dev.vmx.X output for the if_vmx-if_vmx tests?


 Simple iperf (standard TCP) results:
 
 vmxnet3jumbo - vmxnet3jumbo
 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr
 
 vmxnet3 - vmxnet3
 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr
 
 
 if_vmx - if_vmx
 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr
 !!!
 if_vmxjumbo - if_vmxjumbo not possible
 
 
 if_em(e1000) - if_em(e1000)
 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr
 
 if_em(e1000)jumbo - if_em(e1000)jumbo
 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr
 
 
 if_igb(e1000e)junmbo - if_igb(e1000e)jumbo
 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr
 
 if_igb(e1000e) - if_igb(e1000e)
 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr
 
 
 f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096
 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr
 
 if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096
 4.81 Gbits/s, load: 65%Sys 0.5%Intr
 
 Conclusion:
 if_vmx performs well compared to the regular emulated nics and standard
 MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3
 performance with regular mtu. If one needs throughput, the missing jumbo
 frame support in if_vmx  is a show stopper.
 
 e1000e is preferable over e1000, even if not officially choosable with
 FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev =
 e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf,
 although the driver e1000e attaches is if_igb!)
 
 Thanks,
 
 -Harry
 

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Harald Schmalzbauer]

 Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime):
 Hi,

 I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
 lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
 the way so there is not much of a resemblance left.

 The driver is in good enough shape I'd like additional testers. A patch
 against -CURRENT is at [1]. 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. 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 with vmxnet3.

I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
5.1U1 and FreeBSD-9.2-RC2
Two guests are connected to one MTU9000 VMware Software Switch.

Simple iperf (standard TCP) results:

vmxnet3jumbo - vmxnet3jumbo
5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr

vmxnet3 - vmxnet3
1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr


if_vmx - if_vmx
1.51 GBits/sec, load: 10-45%Sys 40-48%Intr
!!!
if_vmxjumbo - if_vmxjumbo not possible


if_em(e1000) - if_em(e1000)
1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr

if_em(e1000)jumbo - if_em(e1000)jumbo
2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr


if_igb(e1000e)junmbo - if_igb(e1000e)jumbo
5.03 Gbits/s, load: 70-60%Sys 0.5%Intr

if_igb(e1000e) - if_igb(e1000e)
1.39 Gbits/s, load: 60-80%Sys 0.5%Intr


f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096
1.66 Gbits/s, load: 65-90%Sys 0.5%Intr

if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096
4.81 Gbits/s, load: 65%Sys 0.5%Intr

Conclusion:
if_vmx performs well compared to the regular emulated nics and standard
MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3
performance with regular mtu. If one needs throughput, the missing jumbo
frame support in if_vmx  is a show stopper.

e1000e is preferable over e1000, even if not officially choosable with
FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev =
e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf,
although the driver e1000e attaches is if_igb!)

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: [CFT] VMware vmxnet3 ethernet driver

[Julian Elischer]

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 of the
VMware tools driver or the emulated e1000?


They are out of tree and subject to rotting. I had to use the patches
at [1] to even get them to compile on 9.1 and -current. I don't think
VMware puts much engineering resources behind it; there was a compiler
warning of a silly bug like:
 if (foo) ;
 do_something();

vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that
the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec
but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences.


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?


[1] - http://ogris.de/vmware/


--
Joel


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- 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 more suitable, but that went no where
over the past year.

It is unfortunate this vendor supplied, out of tree driver, issue is
still around. Linux should have taught companies how foolish this is.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- Original Message -
 Perhaps not, but they do support FreeBSD. I've started several support cases
 with FreeBSD-specific problems and they've fixed all so far.
 

Yes, it is not a blackhole of support. 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
 drivers?
 

I'd like as much as possible to work out of the box. vmxnet3 is as far as
my current interests go. OpenBSD has a vmt device that apparently does (at
least the important bits of) what vmtoolsd does; I'll look at that closer
at some point.

I have no intention of preventing people from using VMware's tools if
they desire, nor breaking existing users.

 --
 Joel
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Joel Dahl]

6 aug 2013 kl. 08:05 skrev Bryan Venteicher bry...@daemoninthecloset.org:

 
 
 - Original Message -
 Perhaps not, but they do support FreeBSD. I've started several support cases
 with FreeBSD-specific problems and they've fixed all so far.
 
 
 Yes, it is not a blackhole of support. 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
 drivers?
 
 
 I'd like as much as possible to work out of the box. vmxnet3 is as far as
 my current interests go. OpenBSD has a vmt device that apparently does (at
 least the important bits of) what vmtoolsd does; I'll look at that closer
 at some point.

Cool. I didn't know about vmt. I read the CVS log in the OpenBSD tree and it 
actually
seems to do most of what I need. Having all this working out of the box 
(without VMware
Tools installed) would be most welcome.

…but I guess VMware would consider this an unsupported configuration or 
something like
that, which sucks if/when I need to contact their support.

--
Joel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Joel Dahl]

On Sun, Aug 04, 2013 at 07:12:17PM -0500, Bryan Venteicher wrote:
 Hi,
 
 I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
 lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
 the way so there is not much of a resemblance left.
 
 The driver is in good enough shape I'd like additional testers. A patch
 against -CURRENT is at [1]. 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. 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 this vmxnet driver instead of the
VMware tools driver or the emulated e1000?

-- 
Joel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- 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 or the emulated e1000?
 

They are out of tree and subject to rotting. I had to use the patches
at [1] to even get them to compile on 9.1 and -current. I don't think
VMware puts much engineering resources behind it; there was a compiler
warning of a silly bug like:
if (foo) ;
do_something();

vmxnet3 has modern features LRO, IPv6 checksum offloading, etc that
the emulated e1000 lacks. In my test setup, e1000 tops out at 30MB/sec
but vmxnet3 goes to 50MB/sec. I'd like to hear other's experiences.

[1] - http://ogris.de/vmware/

 --
 Joel
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [CFT] VMware vmxnet3 ethernet driver

[Joel Dahl]

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 use this vmxnet driver instead of the
  VMware tools driver or the emulated e1000?
  
 
 They are out of tree and subject to rotting. I had to use the patches
 at [1] to even get them to compile on 9.1 and -current. I don't think
 VMware puts much engineering resources behind it;

Perhaps not, but they do support FreeBSD. I've started several support cases
with FreeBSD-specific problems and they've fixed all so far.

Are you aiming at completely replacing VMware tools, or just the device
drivers?

-- 
Joel
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

Hi,

I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
the way so there is not much of a resemblance left.

The driver is in good enough shape I'd like additional testers. A patch
against -CURRENT is at [1]. 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. Hopefully it is no worse :)

The drivers supports most VMXNET3 features - IPv4/IPv6 checksum offload,
TSO, LRO, VLAN tag offload. AFAIK, the only notable missing feature is
multiqueue; 3/4 of the code needed is already in the driver, but I don't
have time to do final bit of work.

Most of the development was done on QEMU 1.5, but also tested on VMware
Fusion and VMware ESXi.

[1] - http://people.freebsd.org/~bryanv/vmware/if_vmx.patch
[2] - http://people.freebsd.org/~bryanv/vmware/files/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Problem with curret in vmware

[Attilio Rao]

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 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
 investigate this?

 Panic screens:
 http://gits.kiev.ua/FreeBSD/panic1.png
 http://gits.kiev.ua/FreeBSD/panic2.png

 Looks like their code needs to be updated to work with locking changes in
 HEAD.  Attilio is probably the best person to ask.

Exactly which is the ports you installed?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Problem with curret in vmware

[Alexander Yerenkow]

That was their official tools, which are came from ISO which mounted with
command  install/upgrade client tools.


2013/8/2 Attilio Rao atti...@freebsd.org

 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 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
  investigate this?
 
  Panic screens:
  http://gits.kiev.ua/FreeBSD/panic1.png
  http://gits.kiev.ua/FreeBSD/panic2.png
 
  Looks like their code needs to be updated to work with locking changes in
  HEAD.  Attilio is probably the best person to ask.

 Exactly which is the ports you installed?

 Attilio


 --
 Peace can only be achieved by understanding - A. Einstein




-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Problem with curret in vmware

[Attilio Rao]

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?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Problem with curret in vmware

[Alexander Yerenkow]

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 their source-code.
 Or do you have any pointer?


No, I just poked here, maybe there is someone who connected with them
somehow.
Currently I'm switched to open-vm tools and wrote in wiki about this caveat.
Probably this is the only way for some time for me :)


 Attilio


 --
 Peace can only be achieved by understanding - A. Einstein




-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Problem with curret in vmware

[Alexander Yerenkow]

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, this could go there too.




2013/7/31 Bryan Venteicher bry...@daemoninthecloset.org

  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.
   This vm aren't shutted down now, is there somethin I can do to help
   investigate this?
  
   Panic screens:
   http://gits.kiev.ua/FreeBSD/panic1.png
   http://gits.kiev.ua/FreeBSD/panic2.png
 
  Looks like their code needs to be updated to work with locking changes in
  HEAD.  Attilio is probably the best person to ask.
 

 This highlights why we should move away from the poorly supported, out of
 tree, unfriendly licensed VMware tools. I have a port of the vmxnet3 from
 OpenBSD [1] that I intend to commit in time for 10. Next, I hope to look
 at the OpenBSD vmt [2] VMware tools driver.

 The balloon is a bit trickier. AFAIK, OpenBSD doesn't have a driver for
 easy porting. The VMware tools driver for FreeBSD is GPL licensed, and
 VMware has shown no interest/ability to relicense their tools. Likely,
 the best way forward is to port their CDDL licensed Solaris driver.

 [1] -
 http://svnweb.freebsd.org/base/projects/vmxnet/sys/dev/vmware/vmxnet3/
 [2] -
 http://www.openbsd.org/cgi-bin/man.cgi?query=vmtapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

  --
  John Baldwin
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 




-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Problem with curret in vmware

[Bryan Venteicher]

 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.
  This vm aren't shutted down now, is there somethin I can do to help
  investigate this?
  
  Panic screens:
  http://gits.kiev.ua/FreeBSD/panic1.png
  http://gits.kiev.ua/FreeBSD/panic2.png
 
 Looks like their code needs to be updated to work with locking changes in
 HEAD.  Attilio is probably the best person to ask.
 

This highlights why we should move away from the poorly supported, out of
tree, unfriendly licensed VMware tools. I have a port of the vmxnet3 from
OpenBSD [1] that I intend to commit in time for 10. Next, I hope to look
at the OpenBSD vmt [2] VMware tools driver.

The balloon is a bit trickier. AFAIK, OpenBSD doesn't have a driver for
easy porting. The VMware tools driver for FreeBSD is GPL licensed, and
VMware has shown no interest/ability to relicense their tools. Likely,
the best way forward is to port their CDDL licensed Solaris driver.

[1] - http://svnweb.freebsd.org/base/projects/vmxnet/sys/dev/vmware/vmxnet3/
[2] - 
http://www.openbsd.org/cgi-bin/man.cgi?query=vmtapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html

 --
 John Baldwin
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Fwd: Problem with curret in vmware

[Alexander Yerenkow]

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
investigate this?

Panic screens:
http://gits.kiev.ua/FreeBSD/panic1.png
http://gits.kiev.ua/FreeBSD/panic2.png

-- 
Regards,
Alexander Yerenkow
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fwd: Problem with curret in vmware

[John Baldwin]

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.
 This vm aren't shutted down now, is there somethin I can do to help
 investigate this?
 
 Panic screens:
 http://gits.kiev.ua/FreeBSD/panic1.png
 http://gits.kiev.ua/FreeBSD/panic2.png

Looks like their code needs to be updated to work with locking changes in
HEAD.  Attilio is probably the best person to ask.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: xorg-server running on 10-current under VMware?

[Dimitry Andric]

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 error:
 AddScreen/ScreenInit failed for driver 0
 
 
 Please consult the The X.Org Foundation support 
   at http://wiki.x.org
 for help. 
 Please also check the log file at /var/log/Xorg.0.log for additional 
 information.
 
 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
 (==) VESA(0): Write-combining range (0x0,0x1000) was already clear
...
 Any hints?

Maybe you can do what it suggests: 'Please also check the log file at 
/var/log/Xorg.0.log for additional information.' ? :-)

-Dimitry

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: xorg-server running on 10-current under VMware?

[Thomas Mueller]

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
  
  
  Please consult the The X.Org Foundation support 
   at http://wiki.x.org
   for help. 
  Please also check the log file at /var/log/Xorg.0.log for additional 
  information.
  
  Segmentation fault at address 0x290
  
  FatalError re-entered, aborting
  Caught signal 11 (Segmentation fault). Server aborting
 
 Any hints?

I'm observing the same behaviour with 10-current running as guest in VirtualBox.

 Program received signal SIGSEGV, Segmentation fault.
 0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) at 
privates.c:79
 79  return *key  *privates 
 Current language:  auto; currently minimal
 (gdb) bt
 #0  0x00454bec in dixLookupPrivate (privates=0x290, key=0x804e2be38) 
at privates.c:79
 #1  0x000804c27310 in ShadowLeaveVT () from 
/usr/local/lib/xorg/modules/libshadowfb.so
 #2  0x0047a076 in AbortDDX () at xf86Init.c:1249
 #3  0x004739fd in AbortServer () at log.c:404
 #4  0x004732b6 in FatalError (f=value optimized out) at log.c:529
 #5  0x004799a9 in InitOutput (pScreenInfo=0x7c5560, argc=3, 
argv=0x7fffdc38) at xf86Init.c:1057
 #6  0x00431f6e in main (argc=3, argv=0x7fffdc38, envp=value 
optimized out) at main.c:204

The segmentation fault in dixLookupPrivate() seems like a subsequent fault of
  xf86Init.c:1043 scr_index = AddScreen(xf86Screens[i]-ScreenInit, argc, argv);
indicating failure to add the screen.

Building xorg-server with gcc
   make USE_GCC=any
or with clang and -O0
   mage CFLAGS=-O0
gives me an X server that appears to work (displays root weave, xterm,
and twm).

-- 
Thomas Mueller
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org