Search results

VMware's hypercall interface uses I/O port knocking, which is used by unprivileged instructions inl/outl and inw/outw (thusly OpenVZ cannot trap them). VMware hypercall 11 allows enumeration of the device tree, you call it and get back 4 bytes of a device table entry at a specified offset. ...

As I said earlier, slabbing is totally fine as long as you are honest about it.

I meant in that context a provider that used a scheme that would benefit from slabbing (i.e. OpenVZ).

version 0.2 of this tool has been tagged in GIT, downloadable here: https://github.com/kaniini/slabbed-or-not/archive/0.2.zip This version is basically all about tickling VMware from inside an OpenVZ container.  If that doesn't apply to your situation, it's probably pretty boring. Interesting...

To play devil's advocate, what is wrong with a properly-secured IIS setup?  IIS is pretty speedy, really.

Interesting... I will pick one up and test with it.

In my opinion the only people who feel threatened by this tool are those which feel it would expose something they are not being transparent about.  Might be worth noting for any future purchase decisions... :)

No drama intended... it's just a tool designed to answer the question of whether or not you're running in a hypervisor or not. Isn't the question "can you determine whether you are running in a hypervisor from within a restricted container" interesting enough without a drama angle?  If not...

Hmm... I am not sure why they would... my post with this thread was basically a technical explanation of how the thing works, as well as the motivation for why I would release a polished up tool for it.

Well, really, I don't care if people use slabs at all... I think you misinterpret my reasoning for releasing this tool. There are some fairly legitimate use cases where slabbing might be advantageous -- live migrations being one of them.  If you've already put in high-availability...

Try version 0.1.1.  It had a late-breaking fix. Basically, to detect if we're running on Xen PV or Xen HVM, we pass an illegal instruction.  On Xen PV, it will be interpreted as a normal instruction, on HVM it will trigger SIGILL (but that doesn't matter because the initial check will pass)...

By flashcache do you mean on the RAID card, or is this mdraid + flashcache? Either way, I can help you do this correctly for a customary fee.

Just download https://github.com/kaniini/slabbed-or-not/archive/0.1.tar.gz Then... cd slabbed-or-not-0.1; make; ./slabbed-or-not

Based on the GVH new Dallas node running in a hypervisor, I decided to begin writing a tool to probe an OpenVZ/LXC environment and see if it is slabbed. There's a few ways we can do this.  First of all, almost all hypervisors provide basic information at CPUID leaf 0x40000000.  So, we can sniff...

Performance & optimization purposes?  Whaaaaaat? He isn't lying though -- it is running as a Xen PV hypervisor... [root@mordor ~]# ./cpuid2 Xen found... checking CPUID leaf 0x40000001 Detected Xen v4.3 [PV] If anyone wants the code... let me know.  I think I will put this on Github so...

Yeah I noticed the hypervisor bit was set later.  Going to see if I can find out more.  It's probably KVM I bet.

I got one of these just now for my own amusement. I am not a huge believer in the 'dd test' as a gold standard, but it seems really off for a box with RAID-10 SSDs. [root@mordor ~]# dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync 16384+0 records in 16384+0 records out 1073741824 bytes...

Precisely what part of your network is Internap?  I see heavy preferencing towards non-Internap carriers in your blend, and the only other provider I was able to reach via Internap was one connected to the same PNAP (Ionity). It seems questionable to advertise Internap bandwidth when it is not...

Well, that is not 100% true really.  Chip-and-PIN transactions have the capability of being push very easily... the transaction can be initiated at the POS terminal. The problem with magstripe is that there's no proof of authenticity, so it pretty much has to be a pull system.

Same.  I am too, idly curious.