is there some docs for how omnios/apache is administrated now? It appears to use privileges (error EACCES [file_dac_write]) outside of any <Directory> entry in httpd.conf

say I have a snapshot of a zone named rpool/zones/ldap0@zadm__pre_ldapmodify, and I would like to deploy a new zone from that snapshot named ldap1... what would be the most OmniOS way of doing that?

The official way would be to use 'zoneadm clone' instead of 'zoneadm install'

Configure as normal, and then something like

zoneadm -z ldap1 clone -s rpool/zones/ldap0@zadm__pre_ldapmodify ldap0

There are all sorts of caveats in documentation about the state of the source zone (you're supposed to halt it)

ptribble I had no idea that I'm supposed to halt it

I can't see that checked anywhere in code, though

And that might just be a documentation leftover from when zones were on UFS and you didn't have the atomicity of a zfs snapshot

Hm. I think zoneadm checks, but it's not clear why it's necessary

I never used the formal clone functionality; we had a hacky way of replicating zones from a snapshot via zfs send/recv instead, which avoids all the afs dependencies you have with clones, and works for building zones on remote machines as well as local

I wonder if zoneadm clone does send/recv or clone...

okay, time to play around

(I feel like the QA of illumos :P)

antranigv - that issue you raised about Hyper-V under Vultr is bizarre

andyf I just installed it again

andyf and I got the output

andyf sending to the issue now

Nice, let's find out what's going on!

and btw... I tried running it on my other machine... is there a reason for cpuid to print the output forever? :P

it's been going for 3 minutes xD

Yes, there are some bugs in cpu emulation

I did fix one bug recently in bhyve that would cause that

got it! it is running on bhyve... the other machine, that is

ah, probably illumos 16223 (fenix)

BUG 16223: bhyve returns bogus cpuid 8000_001D leaf (Closed)

↳ illumos.org/issues/16223 | code.illumos.org/c/illumos-gate/+/3250

That's affected in FreeBSD as well, then.

Yes, the bug is there too

I have not sent it their way yet.

andyf here you go: omniosorg/illumos-omnios #1432#issuecomment-1948671446

Ok, do you see the line in the output you shared for CPUID leaf 4000000?

CPUID 40000000:00 = 40000005 7263694d 666f736f 76482074 | ...@Microsoft Hv

Yup

The system is identifying itself as Hyper-V

that is so weird

I did confirm with support that it's KVM, and the BSD Loader says KVM as well

See github.com/illumos/illumos-gate/blo…intel/sys/x86_archext.h#L1780-L1788

For KVM, we'd see KVMKVMKVM or TCGTCGTCGTCG

Oh, BSD is showing KVM? Interesting.

If you have a conversation going with support, it would be worth sharing that output and asking them about the hypervisor signature!

andyf sir yes sir... I'll open a ticket again

In the illumos loader screenshot you added it does have QEMU and KVM in the smbios information.

This might be relevant community.netdata.cloud/t/vultr-lin…ect-it-as-microsoft-any-idea/3535/3

Which makes it sound like they are running QEMU/KVM but hacking in some Hyper-V emulation. Cracking!

feels like browser user agents where everybody is just lying about everything

They identify as hyper-v just enough to make some windows drivers work, it appears, but not enough that we can actually boot with it.

It's enlightenment!

haha

I'm not sure how we could detect that..

Well, maybe we can, depending on where it crashes.

Otherwise I'd suggest disabling the hv_vmbus driver as you're doing, or disabling platform detection entirely (which would be "echo set enable_platform_detection = 0 > /etc/system.d/platform")

andyf I guess that's because I'm using a custom OS. The FreeBSD ones say it's KVM indeed. But I do wonder, how is the BSD Loader detecting

andyf not an issue per say, but maybe we can document it somewhere on the website?

Does the illumos loader do the same thing as BSD?

I think it's getting it from the smbios information that the hypervisor presents

andyf apologies, when I say "the BSD Loader" I mean the FreeBSD loader in illumos :D

so the illumos loader, does indeed, say KVM

Ah, ok, sorry, with you talking about FreeBSD guests too I got confused. The illumos loader is a fork of the FreeBSD one. IF you still have a guest, you can use `smbios -t1` and `smbios -t2` to see the smbios information. That will say KVM/QEMU.

Vultr's platform is truly split-brain

andyf I can complain to the CTO, if needed :P

I took a snapshot of the VM so... checking again!!!

andyf here's some output: gist.github.com/antranigv/c015755a474dc70158e0747d2774d5b0

Yeah, Manufacturer: QEMU; Family: KVM

andyf so basically, some part of it is reporting KVM while the other Hyper-V?

Yes. It's KVM/QEMU but they have patched in a different hypervisor ID and emulated enough MSRs and other things to convince windows enlightened drivers to work. When we check during boot, it looks like Hyper-V.

andyf I see

Does anyone happen to have an omnios 048 vm with NVMe up?

(Or non-VM)

Yes, under propolis

Can you sanity check the ability to print the n_idctl field in the nvme_t gets data? ala *nvme_state::walk softstate | ::print nvme_t n_idctl[]

Context is illumos.topicbox.com/groups/develop…bd9418586-M78fe69364042867e3dac0573.

OK, so it does owrk.

a lot of zeros, but the first few fields look good

I'll try to reply with the right syntax.