Install successful on EliteBook 8560w (v. 715), but what's next?

[Jean-Philippe Oudet]

Hello,

First of all: Nice job guys!

The install wasn't easy, but some Google-Fu helped so far. Used Rufus in DD mode, to be sure.

Version 715 installed, with Measured Launched, LAN, Wifi, print reader, webcam, DVD, audio, and the "HP integrated Module" recognized.

Just, for those trying the same hardware: the BIOS needs to be updated. I used the last one (F61 pass 2, you can find it in the HP website, only under Win7). If you have troubles with the TPM, go back to the BIOS, clear the TPM (after disabling the TXT), then re-enable TXT and TPM. And use the Alt-Consoles to find why it's not working. Also, I had to manually format the SSD I'm using (it's a innodisk SED, but whatever, did it too for a non-SED SSD).

Note that you will not have access to the i7 GPU, since ... it's not connected at all. Do not look in the BIOS a switch.

I tried the RELEASE (v6), but got stuck in the install (do not remember where), then I switch to the v7. Since I want to experiment with it, that's fine. Unless someone tells me otherwise, perhaps from the following remarks.

• there are no ways to pass a USB key to the VM? Or at least emulate a CD/DVD with an ISO?
• local password disabled? No screen locks?
• VPN unavailable? No idea where to setup a VPNVM ...
• NDVM per NIC? I see what looks like a single VM for both NIC.

Then, for SSH, I had to:

• Ctrl+Shit+T (terminal from the OpenXT UI, root/"password you setup during the installation")
  
• newrole -r sysadm_r 
• xec set enable-dom0-networking true

Should be more usable to activate SSH. 

And not sure about the difference with:

• nr    #alias for newrole-to-admin.

• xec set enable-ssh true

But now I have a SSH console to dom0 (only via Ethernet, BTW ...). 

But no access to /storage (permissions?). I suppose it's not supposed to be so difficult to upload a file to dom0?

Should I add a LVM volume?

Can I add an external drive, at least, as a repository?

Finally, what would you do when their is not Intel eGPU available? I think I saw something related to the driver in the console during install.

Can we try to use a Nvidia driver for OpenXT? Or at least pass through the MXM module to one of the VM?

They are claiming to use them in SecureView, is that the role of MultiView/ConnectView? Is it possible to do it only at the OpenXT level?

Keep up the good work.

[Rich Persaud]

On Mar 21, 2017, at 13:55, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:

Hello,

First of all: Nice job guys!

The install wasn't easy, but some Google-Fu helped so far. Used Rufus in DD mode, to be sure.

Version 715 installed, with Measured Launched, LAN, Wifi, print reader, webcam, DVD, audio, and the "HP integrated Module" recognized.

Just, for those trying the same hardware: the BIOS needs to be updated. I used the last one (F61 pass 2, you can find it in the HP website, only under Win7). If you have troubles with the TPM, go back to the BIOS, clear the TPM (after disabling the TXT), then re-enable TXT and TPM. And use the Alt-Consoles to find why it's not working. Also, I had to manually format the SSD I'm using (it's a innodisk SED, but whatever, did it too for a non-SED SSD).

Note that you will not have access to the i7 GPU, since ... it's not connected at all. Do not look in the BIOS a switch.

Does this laptop have both an Intel integrated GPU and an Nvidia GPU, with Optimus for switching?  OpenXT only supports shared access to the Intel integrated GPU and dedicated (passthrough) access to discrete GPUs (usually a PCI card on a desktop, not a secondary GPU on a laptop).

This laptop has a Sandy Bridge CPU?  You may be more successful with an Ivy Bridge, Haswell, Broadwell or Skylake laptop that has only an Intel integrated GPU, no secondary GPU.

I tried the RELEASE (v6), but got stuck in the install (do not remember where), then I switch to the v7. Since I want to experiment with it, that's fine. Unless someone tells me otherwise, perhaps from the following remarks.

• there are no ways to pass a USB key to the VM? Or at least emulate a CD/DVD with an ISO?

On the stable (6.0) release, you should be able to attach USB devices to Linux and Windows VMs which have guest tools (PV drivers) installed.   There are options in the UIVM (user interface VM, a.k.a. local GUI management console) under VM properties.

ISOs can be copied to /storage/iso in dom0, then can be selected in the UIVM from VM properties, to mount the ISO as a virtual optical drive in the guest.

• local password disabled? No screen locks?

This is an unfortunate, open bug:

 https://openxt.atlassian.net/browse/OXT-292

• VPN unavailable? No idea where to setup a VPNVM ...

Some old instructions are available in Section 3.3 (NILF, Network In-Line Filter) of the Developer guide, but may not apply to recent versions of OpenXT:

 https://raw.githubusercontent.com/OpenXT-Extras/docs/master/snapshot/XTEngineDeveloperGuide.pdf

• NDVM per NIC? I see what looks like a single VM for both NIC.

See Section 5.4 of the Administrator guide:

 https://raw.githubusercontent.com/OpenXT-Extras/docs/master/snapshot/XTEngineAdministratorGuide.pdf

Then, for SSH, I had to:

• Ctrl+Shit+T (terminal from the OpenXT UI, root/"password you setup during the installation")
  
• newrole -r sysadm_r 
• xec set enable-dom0-networking true

Should be more usable to activate SSH. 

And not sure about the difference with:

• nr    #alias for newrole-to-admin.

• xec set enable-ssh true

I'm not 100% sure, but the first command likely connects a virtual network interface to dom0, while the second command likely enables the SSH server in dom0.

But now I have a SSH console to dom0 (only via Ethernet, BTW ...). 

But no access to /storage (permissions?). I suppose it's not supposed to be so difficult to upload a file to dom0?

Should I add a LVM volume?

Can I add an external drive, at least, as a repository?

SE Linux mandatory access control will limit the operations that are allowed in dom0.   It can be disabled temporarily.   You can also check /var/log/messages for error msgs from SE Linux.

https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing

You can mount external drives or LVM volumes manually.  If you want the mount to persist beyond reboot, you will need to modify /etc/fstab, which is on a read-only partition that is also measured at boot.  You can remount the root filesystem read-write to make the modification.  At the next boot, measured launch will indicate that the filesystem has changed, and you can approve the change after entering the root password.

Finally, what would you do when their is not Intel eGPU available? I think I saw something related to the driver in the console during install.

This is not easy to diagnose remotely.  There may be clues in /var/log/.   A more modern vPro laptop, with only an Intel GPU, would have a better chance of working.   Other people on the list may have tips on debugging the problem with the Intel GPU.

Can we try to use a Nvidia driver for OpenXT? Or at least pass through the MXM module to one of the VM?

Nvidia GPUs don't typically work on laptops with OpenXT.  Even on desktops, Nvidia disables (at the level of in-guest drivers) support for GPU passthrough, except on higher end video cards.   Your best bet is a laptop with only an Intel GPU.

Rich

[Jean-Philippe Oudet]

On Tuesday, March 21, 2017 at 5:34:45 PM UTC-4, Rich Persaud wrote:

Does this laptop have both an Intel integrated GPU and an Nvidia GPU, with Optimus for switching?  OpenXT only supports shared access to the Intel integrated GPU and dedicated (passthrough) access to discrete GPUs (usually a PCI card on a desktop, not a secondary GPU on a laptop).

Yes and no, the i7-2820 has a iGPU, but AFAIK it's completely deactivated for the MXM module, a Nvidia Quadro (1000M I think). 

No Optimus. Anyways, who made this work IRL??? ;-)

I believe OpenXT is currently displaying the UI on the Nvidia GPU, probably with a software renderer, as it's often the case. The resolution is not good. Perhaps 1024x728?

So, essentially, you are saying OpenXT is sharing everything on the iGPU, but you can dedicate an external GPU to a VM and process heavy stuff on it but only within this VM? I read something like that.

I'm not really sure, but I believe this GPU (the Nvidia) will be either constrained (limited) by the available drivers if I try to share it, or I won't be able to use it at all unless it's possible to switch it for OpenXT, then for each VM?

But bottom line, what I have today is normal and expected. OpenXT doesn't work on a shared Nvidia GPU?

This laptop has a Sandy Bridge CPU?  You may be more successful with an Ivy Bridge, Haswell, Broadwell or Skylake laptop that has only an Intel integrated GPU, no secondary GPU.

Sure, but for the moment, I work with this laptop. My current goal is to understand it more for its capabilities. My interest rely more in the structure, isolation, CSfC capabilities, GPU redirection ... 

This platform is also interesting for its extensibility (I can change the GPU, if that's required, or add another disk). Not that helps for the Intel GPU, unfortunately. But that's a lesson learnt.

Also, I should have access to SecureView soon.

Still, their is this mention in the docs: "Multiple GPU and seamless mouse support, allowing you to run multiple 3D Graphics Support VMs on separate monitors". I want to understand that better.

I tried the RELEASE (v6), but got stuck in the install (do not remember where), then I switch to the v7. Since I want to experiment with it, that's fine. Unless someone tells me otherwise, perhaps from the following remarks.

• there are no ways to pass a USB key to the VM? Or at least emulate a CD/DVD with an ISO?

On the stable (6.0) release, you should be able to attach USB devices to Linux and Windows VMs which have guest tools (PV drivers) installed.   There are options in the UIVM (user interface VM, a.k.a. local GUI management console) under VM properties. ISOs can be copied to /storage/iso in dom0, then can be selected in the UIVM from VM properties, to mount the ISO as a virtual optical drive in the guest.

Yeah, I saw it. But I do not have access to /storage (see below). So it looks like another bug of the v.7?

And to attach a USB drive to a VM, you need it to exist (and install the tools) ... catch-22!

  

• local password disabled? No screen locks?

This is an unfortunate, open bug:

 https://openxt.atlassian.net/browse/OXT-292

Ok. I'll investigate then report. 

• VPN unavailable? No idea where to setup a VPNVM ...

Some old instructions are available in Section 3.3 (NILF, Network In-Line Filter) of the Developer guide, but may not apply to recent versions of OpenXT:

 https://raw.githubusercontent.com/OpenXT-Extras/docs/master/snapshot/XTEngineDeveloperGuide.pdf

Thanks for the link. Any source of info is precious! ;-) 

• NDVM per NIC? I see what looks like a single VM for both NIC.

See Section 5.4 of the Administrator guide:

 https://raw.githubusercontent.com/OpenXT-Extras/docs/master/snapshot/XTEngineAdministratorGuide.pdf

Nice one.

It's very hard to find the "good document", it's disseminated everywhere! Sorry. And thanks for this one.

 

Then, for SSH, I had to:

• Ctrl+Shit+T (terminal from the OpenXT UI, root/"password you setup during the installation")
  
• newrole -r sysadm_r 
• xec set enable-dom0-networking true

Should be more usable to activate SSH. 

And not sure about the difference with:

• nr    #alias for newrole-to-admin.

• xec set enable-ssh true

I'm not 100% sure, but the first command likely connects a virtual network interface to dom0, while the second command likely enables the SSH server in dom0.

Virtual NIC? My goal was to connect the real eth0.

 

But now I have a SSH console to dom0 (only via Ethernet, BTW ...). 

But no access to /storage (permissions?). I suppose it's not supposed to be so difficult to upload a file to dom0?

Should I add a LVM volume?

Can I add an external drive, at least, as a repository?

SE Linux mandatory access control will limit the operations that are allowed in dom0.   It can be disabled temporarily.   You can also check /var/log/messages for error msgs from SE Linux.

https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing

You can mount external drives or LVM volumes manually.  If you want the mount to persist beyond reboot, you will need to modify /etc/fstab, which is on a read-only partition that is also measured at boot.  You can remount the root filesystem read-write to make the modification.  At the next boot, measured launch will indicate that the filesystem has changed, and you can approve the change after entering the root password.

So ... Basically it's "normal behaviour" not to present the storage mount to the UI? May I ask why this is desired?

I can SSH to dom0 without manipulating SELinux, but the permission on /storage are not letting me use it. But I can delete everything else? Looks more like a bug to me.

Noted for the mounting and Measured Launch. I'll have to look into that after I understand what i'm doing. Ideally ;-) ...

 

Finally, what would you do when there is no Intel iGPU available? I think I saw something related to the driver in the console during install.

This is not easy to diagnose remotely.  There may be clues in /var/log/.   A more modern vPro laptop, with only an Intel GPU, would have a better chance of working.   Other people on the list may have tips on debugging the problem with the Intel GPU.

Sure. 

But I also saw plenty other Elitebook supported in the list. I doubt they are all so different than mine. I've not validated, but I doubt mine is the only one not using the Intel GPU.

So, it looks like more and more like another bug. I will confirm with the latest STABLE version, now that the BIOS is up to date, that could work. I'll update this post.

Can we try to use a Nvidia driver for OpenXT? Or at least pass through the MXM module to one of the VM?

Nvidia GPUs don't typically work on laptops with OpenXT.  Even on desktops, Nvidia disables (at the level of in-guest drivers) support for GPU passthrough, except on higher end video cards.   Your best bet is a laptop with only an Intel GPU.

Again, that's strange. SecureView is supposed to allow several VM displayed from several GPU. If the hypervisor is not designed to allow that, I missing something.

I understand the Intel GPU is crucial for the UIVM, but you should be allowed to pass the other GPU to the VM. In fact, ideally, once passed through, the hypervisor should not see it at all and the VM handles the PCI calls.

Also, it's a MXM module, and I have access to more modern Nvidia GForce and AMD alternatives. If the Quadro is a NOGO. Can try another one.

But I was interested in the 1000M-MXM because of that:

GPU Pass-through with

• Citrix XenDesktop 5.6 FP1 Enterprise/Platinum, XenServer 6 Enterprise / Platinum editions

• VMware Horizon View 5.2 and vSphere 5.1
  

or

https://www.citrix.com/blogs/2014/01/14/xenserver-and-xendesktop-nvidia-support-for-gpu-passthrough-on-cards-including-the-k5000/

In the end, if I want to experiment my interests in isolated VMs (so, at least 2 GPU), what laptop should I choose?

 

Rich

Thank you Rich.

And I'll update the situation with a v.6.

[eric chanudet]

Some thoughts, catching up on that...

On Tue, Mar 21, 2017 at 8:02 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> On Tuesday, March 21, 2017 at 5:34:45 PM UTC-4, Rich Persaud wrote:
>> Does this laptop have both an Intel integrated GPU and an Nvidia GPU, with
>> Optimus for switching? OpenXT only supports shared access to the Intel
>> integrated GPU and dedicated (passthrough) access to discrete GPUs (usually
>> a PCI card on a desktop, not a secondary GPU on a laptop).
>
> Yes and no, the i7-2820 has a iGPU, but AFAIK it's completely deactivated
> for the MXM module, a Nvidia Quadro (1000M I think).
> No Optimus. Anyways, who made this work IRL??? ;-)
>
> I believe OpenXT is currently displaying the UI on the Nvidia GPU, probably
> with a software renderer, as it's often the case. The resolution is not
> good. Perhaps 1024x728?

That seems right. In this case, having the Nvidia as primary GPU will
have Surfman use fbdev copy plugin as a fallback (usual for Intel GPU
is drm-plugin). I believe there is a ticket in to restore the DRM copy
fallback logic, which should handle larger screen definition. There is
no plan to attend this one soon though.

> So, essentially, you are saying OpenXT is sharing everything on the iGPU,
> but you can dedicate an external GPU to a VM and process heavy stuff on it
> but only within this VM? I read something like that.

A "default" configuration would be UIVM and guests using PV drivers or
the emulated stdvga from QEMU being displayed by Surfman's DRM plugin
on the Intel GPU. Any guest can be assigned another PCI GPU and use it
on its own, with other guests still being displayed on the Intel GPU.

> But bottom line, what I have today is normal and expected. OpenXT doesn't
> work on a shared Nvidia GPU?

If I understood correctly, that is right.

> Sure, but for the moment, I work with this laptop.

Firmware usually offers a configuration to decide to either use the
Intel GPU or the discrete one as primary. Having the Intel as primary
should allow you to pass-through the Nvidia one to a guest.

> Still, their is this mention in the docs: "Multiple GPU and seamless mouse
> support, allowing you to run multiple 3D Graphics Support VMs on separate
> monitors". I want to understand that better.

The use case I know about that matches this description is having 1+
GPU passed through to 1+ guest with pv-tools installed. PV-tools will
allow for the mouse pointer to move from one guest, with GPU passed
through, to another (screen position can be configured through the
UIVM on the Intel GPU). So that is 1 guest <-> 1 GPU and whatever is
displayed on the integrated Intel GPU (UIVM or guests using QEMU's
stdvga/pv-drivers).

> Yeah, I saw it. But I do not have access to /storage (see below). So it
> looks like another bug of the v.7?

Using the "nr" alias (to "newrole -r sysadm_r") should give you access
to /storage, which is not read-only. Default place for vhds is
/storage/disks and isos /storage/isos, the UI and toolstack should
pick up on that. You might want to look at /config/vms/<uuid>.db file
to change disks paths and run "killall -HUP dbd" to update the db for
the toolstack to use.

> And to attach a USB drive to a VM, you need it to exist (and install the
> tools) ... catch-22!

:D. Plugin a USB key to a guest with tools, while the guest is
displayed, should assign that USB to the guest unless enforced
otherwise? I have not played a lot with that, so that statement is not
reliable. Anyway you should have access to /storage once admin.

>> And not sure about the difference with:
>>> nr #alias for newrole-to-admin.

Switches to role sysadm_r. (alias to newrole -r sysadm_r)
>>> xec set enable-ssh true
That enables sshd in dom0.

> Virtual NIC? My goal was to connect the real eth0.

By default, NDVM is started with NICs passed-through. Dom0 only has a
xennet pv frontend used, for example, for sshd.

>> But now I have a SSH console to dom0 (only via Ethernet, BTW ...).
>> But no access to /storage (permissions?). I suppose it's not supposed to
>> be so difficult to upload a file to dom0?
>> Should I add a LVM volume?

That might be difficult with only one disk. I am under the assumption
the installer will use the entire disk at installation (having
"whatever is free" for /storage). You should be able to shrink
xenclient-storage and add a volume to the VG though if really
necessary.

> So ... Basically it's "normal behaviour" not to present the storage mount to
> the UI?

The use of the terminal is not considered default behavior in enforced
mode. Presumably everything should be doable through the UI.

>> Finally, what would you do when there is no Intel iGPU available? I think
>> I saw something related to the driver in the console during install.

Headless OpenXT was mentioned at some point. AFAIK this is not supported yet.
Otherwise, Surfman will fallback to the fbdev plugin to provide some form of UI.

> But I also saw plenty other Elitebook supported in the list. I doubt they
> are all so different than mine.

Devil's in the details unfortunately... There should be an HP
Elitebook I can get my hands on, and will be looking at GPU
pass-through issues. Without any commitment, if I have the time I will
give it a spin.

> Again, that's strange. SecureView is supposed to allow several VM displayed
> from several GPU. If the hypervisor is not designed to allow that, I missing
> something.

Someone familiar with SV can likely answer that. It is my
understanding that SV uses a very different graphic stack (not
Surfman).

--
Eric CHANUDET

[eric chanudet]

On Tue, Mar 21, 2017 at 8:02 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:

> I believe OpenXT is currently displaying the UI on the Nvidia GPU, probably
> with a software renderer, as it's often the case. The resolution is not
> good. Perhaps 1024x728?

Now that I think of it, I believe the OpenXT graphic stack does not support
large resolutions (e.g. 3840x2160, or above 1920x1200?), which could
also explain the poor resolution as it will likely fallback to some
VESA mode (likely 1024x768). In this case the Nvidia GPU should be
available to be passed-through to a guest though.

--
Eric CHANUDET

[Jean-Philippe Oudet]

Update:

Installed 6.0.1 (build 729)

Note to self (and others interested), this BIOS requires to reboot another time (2 times) after resetting the TPM, otherwise the install stops. [So if you're told the TPM is not activated, just reboot].

Now, what changed:

1/ GPU detected this time. As a GF108GLM, Quadro 1000M.

2/ UI Managment Terminal (Ctrl+Shift+T) doesn't give access to /storage out-of-the-box (or lost+found). "nr" gives local access, but still no access via SSH.

What's the same:

a/ Brightness controls still do not work ... (also, from the documentation [XTEngineAdministratorGuide, p39], I saw it should be other stuff in this windows (Display Adapter, Mouse Switching) that I do not see in mine)

b/ Screen Lock, but that expected (bug tracked)

c/ Still no access to /storage via SSH: "permission denied". "/lost+found" too.

Storage

While adding a LVM storage seems possible, I do not understand why it should be so complex OOTB. I still haven't had the time to read the docs in the thread, but just as a new user, I would be discouraged by that. That'd be a significant show stopper if that's really the intended way. Why restricting from the UI access to /storage/iso???

How do you install the OS in a normal case: only with a DVD passed through to the VM?

I ask that to better understand what's considered safe.

Otherwise, the

nr 

setenforce 0

rw

copy of the ISO via SCP

then  

setenforce 1 
ro

should be just automated. A simple GUI to access the datastore (/storage/isos) would help a lot, ala ESXi 6.5 (HTML 5 pop-up).

[Note that /tmp is relatively small, I tried that before find the above commands to disable SELinux. Mine is 105M. Note very helpful to dump an OS installation ISO.]

Graphics

Where can I educate myself about Surfman? Is it possible to understand how SV workaround the GPU issues? I understand i7 is much easier to support (and ubiquitous), but supporting the Nvidia stack should be possible, right? Nowadays, there are a lot of Nvidia GPU around. I'm not putting pressure, just trying to understand the required level of effort (and expected timeline) for OpenXT to support Nvidia GPU as the shared GPU. 

I believe it should be much clearer for the newcomers that an Intel iGPU is required (as for today).

Now, if (when) I want to look for a better mobile platform with dedicated GPU, what should I look for? Switchable graphics are not exactly well documented in the marketing material when you buy a new laptop. But if I want a dedicated GPU for a specific VM, but all other rendering tasks on the Intel GPU, what are the guidelines to choose the platform?

Debian Install

Oddly, the install was using half the screen (left, discoloured)! I assume this is related to the above and not been really supported by the driver.

Then, I saw the full screen "pretty" environment. But it auto-updated then I'm stuck with the black screen that I assume is caused by the DRM?

Now I'm there.

I'm reading the documentation now.

Thanks for the discussion and the tips.

[Jean-Philippe Oudet]

On Thursday, March 23, 2017 at 12:29:27 PM UTC-4, Eric Chanudet wrote:

Some thoughts, catching up on that...

On Tue, Mar 21, 2017 at 8:02 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> On Tuesday, March 21, 2017 at 5:34:45 PM UTC-4, Rich Persaud wrote:
>> Does this laptop have both an Intel integrated GPU and an Nvidia GPU, with
>> Optimus for switching?  OpenXT only supports shared access to the Intel
>> integrated GPU and dedicated (passthrough) access to discrete GPUs (usually
>> a PCI card on a desktop, not a secondary GPU on a laptop).
>
> Yes and no, the i7-2820 has a iGPU, but AFAIK it's completely deactivated
> for the MXM module, a Nvidia Quadro (1000M I think).
> No Optimus. Anyways, who made this work IRL??? ;-)
>
> I believe OpenXT is currently displaying the UI on the Nvidia GPU, probably
> with a software renderer, as it's often the case. The resolution is not
> good. Perhaps 1024x728?
That seems right. In this case, having the Nvidia as primary GPU will
have Surfman use fbdev copy plugin as a fallback (usual for Intel GPU
is drm-plugin). I believe there is a ticket in to restore the DRM copy
fallback logic, which should handle larger screen definition. There is
no plan to attend this one soon though.

I think I saw this ticket. 

Honestly, if that just a problem of resolution, I believe it is ok for now.

If I understand the impact, when you have a single GPU, and you're limited with only switching back and forth from VM to OpenXT UI to another VM, it's ok. You're loosing the "multiview" capability. Good. I think.

Now, I do not understand the impact on security doing that. Are you still maintaining the isolation between the VMs?

The red part above, I do not understand yet.

> So, essentially, you are saying OpenXT is sharing everything on the iGPU,
> but you can dedicate an external GPU to a VM and process heavy stuff on it
> but only within this VM? I read something like that.
A "default" configuration would be UIVM and guests using PV drivers or
the emulated stdvga from QEMU being displayed by Surfman's DRM plugin
on the Intel GPU. Any guest can be assigned another PCI GPU and use it
on its own, with other guests still being displayed on the Intel GPU.

 

What about doing that with any GPU?

What's Surfman? The GUI? [Sorry, but I have a long way to go for the technicalities.]

For the rest, I think I understand (PCI GPU dedicated to one VM), or I will experiment.

 

> But bottom line, what I have today is normal and expected. OpenXT doesn't
> work on a shared Nvidia GPU?
If I understood correctly, that is right.

That's unfortunate. Is it related to a lack of drivers?

Is it something possible to do in this regard? Or it's just to complex?

 

> Sure, but for the moment, I work with this laptop.
Firmware usually offers a configuration to decide to either use the
Intel GPU or the discrete one as primary. Having the Intel as primary
should allow you to pass-through the Nvidia one to a guest.

Yeah, unfortunately, I found out HP sells two SKU, with 2 Motherboards: 1 is for the i7+Nvidia/AMD GPU, 1 is for the i7+ its integrated GPU.

My laptop is with the external GPU, so the i7 is not even connected physically to the video outputs.

Crappy design. But as I said, I'm just trying to understand, for now.

If someone has a recommendation for a good secure, rugged but portable laptop, let me know what's your preferences!

It's also time for me to upgrade my work laptop.

> Still, their is this mention in the docs: "Multiple GPU and seamless mouse
> support, allowing you to run multiple 3D Graphics Support VMs on separate
> monitors". I want to understand that better.
The use case I know about that matches this description is having 1+
GPU passed through to 1+ guest with pv-tools installed. PV-tools will
allow for the mouse pointer to move from one guest, with GPU passed
through, to another (screen position can be configured through the
UIVM on the Intel GPU). So that is 1 guest <-> 1 GPU and whatever is
displayed on the integrated Intel GPU (UIVM or guests using QEMU's
stdvga/pv-drivers).

I found this in the XTEngineAdministratorGuide, at the beginning (Intro).

I really need to read something about the architecture of OpenXT. I need to add the drivers stack to my TODO list of readings.

But as I said, in my case, the Adapter+Mouse Switching preferences are not displayed in the UI. If that's what you're telling me.

I think it's logical that when you have only 1 GPU, you can still see the different VMs switching from one to another. The "seamless" transition is a big plus, to be clear, but that could be an acceptable situation as fall back.

> Yeah, I saw it. But I do not have access to /storage (see below). So it
> looks like another bug of the v.7?
Using the "nr" alias (to "newrole -r sysadm_r") should give you access
to /storage, which is not read-only. Default place for vhds is
/storage/disks and isos /storage/isos, the UI and toolstack should
pick up on that. You might want to look at /config/vms/<uuid>.db file
to change disks paths and run "killall -HUP dbd" to update the db for
the toolstack to use.

I found the explanation for the SELinux enforcement limiting the write access to the /storage folder. Once I deactivated it, everything worked.

I questioning this design choice, especially when I see you can manage the permission for an "sys admin" and a "user". I would let a sys admin have access to a repository to upload isos and whatnot, without the need to disable the enforcement. Or even let the access to /storage/isos open at all time?

Also, it should be easily automated (disabling the enforcement, uploading the file, reenabling SELinux)

Same thing for the role change. With a UI "admin" menu? Or within the "Settings" menu. 

Just a suggestion.

 

> And to attach a USB drive to a VM, you need it to exist (and install the
> tools) ... catch-22!
:D. Plugin a USB key to a guest with tools, while the guest is
displayed, should assign that USB to the guest unless enforced
otherwise? I have not played a lot with that, so that statement is not
reliable. Anyway you should have access to /storage once admin.

Admin + SELinux disabled.

It should be as easy to do as it is with a CD/DVD, I believe. From a user's perspective.

>> And not sure about the difference with:
>>> nr    #alias for newrole-to-admin.
Switches to role sysadm_r. (alias to newrole -r sysadm_r)
>>> xec set enable-ssh true
That enables sshd in dom0.

Yeah, hummm ... my question was more: what "xec set enable-dom0-networking true" does that "xec set enable-ssh true" does not, to enable SSH?

I think SSH is enabled for the get go (during install), but I still had to use the second command to make it work (and finding the IP address wasn't trivial).

When I reinstalled the v.6, SSH and the networking worked OOTB. Something wasn't correct in the v.7.

 

> Virtual NIC? My goal was to connect the real eth0.
By default, NDVM is started with NICs passed-through. Dom0 only has a
xennet pv frontend used, for example, for sshd.

Needs some reading, so.

 

>> But now I have a SSH console to dom0 (only via Ethernet, BTW ...).
>> But no access to /storage (permissions?). I suppose it's not supposed to
>> be so difficult to upload a file to dom0?
>> Should I add a LVM volume?
That might be difficult with only one disk. I am under the assumption
the installer will use the entire disk at installation (having
"whatever is free" for /storage). You should be able to shrink
xenclient-storage and add a volume to the VG though if really
necessary.

I remember doing something similar with XenServer (5.5?) for a LVM mount.

Anyways, question solved for uploading an ISO.

> So ... Basically it's "normal behaviour" not to present the storage mount to
> the UI?
The use of the terminal is not considered default behavior in enforced
mode. Presumably everything should be doable through the UI.

It is (clearly?) not possible to upload any kind of file through the UI, AFAIK... 

Did I miss a button or something?

>> Finally, what would you do when there is no Intel iGPU available? I think
>> I saw something related to the driver in the console during install.
Headless OpenXT was mentioned at some point. AFAIK this is not supported yet.
Otherwise, Surfman will fallback to the fbdev plugin to provide some form of UI.

So, yes, there is difference between v.6 and v.7 about the Nvidia driver. I do not much more.

But the "some form of UI" is an as good solution as an headless OXT as long as I can have full resolution within my VMs (even one at a time). If that's really the case, I'd not mind the present situation. It's like starting a fancy BIOS to configure/select which VM I want to start. Good enough.

But if you can have a seamless transition from one to another with an Intel GPU, even better.

If you can display 2+ VM at the same time, with full isolation, then you have an very awesome and exciting new product that can have a lot of attention!

> But I also saw plenty other Elitebook supported in the list. I doubt they
> are all so different than mine.
Devil's in the details unfortunately... There should be an HP
Elitebook I can get my hands on, and will be looking at GPU
pass-through issues. Without any commitment, if I have the time I will
give it a spin.

You are right. I learnt my model is one of the few without any access to the Intel GPU. So, perhaps all the other Elitebooks in the OpenXT Supported Hardware do not have this problem.

Still, please consider supporting dedicated/accelerated Nvidia/AMD GPU as a feature request, if that's not already the case.

But you should probably add the EliteBook 8560w as a supported model, with the caveat that only the SKU without a dedicated GPU is fully compatible.

> Again, that's strange. SecureView is supposed to allow several VM displayed
> from several GPU. If the hypervisor is not designed to allow that, I missing
> something.
Someone familiar with SV can likely answer that. It is my
understanding that SV uses a very different graphic stack (not
Surfman).

I'll have to look into that.

I'd be soon capable to have access to it. 

--
Eric CHANUDET

Thanks Eric. 

[eric chanudet]

On Fri, Mar 24, 2017 at 9:53 AM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> On Thursday, March 23, 2017 at 12:29:27 PM UTC-4, Eric Chanudet wrote:
>> Surfman use fbdev copy plugin as a fallback (usual for Intel GPU
>> is drm-plugin).

> What's Surfman? The GUI? [Sorry, but I have a long way to go for the
> technicalities.]

My bad, I should have explained that further.
OpenXT uses a daemon called Surfman, in dom0, to display VMs on
screen. For legacy reasons, Surfman can use various plugins to handle
displaying through different means. The default plugin is "drm-plugin"
which uses the DRM API, the Intel sub-component of DRM (i915)
specifically, to create framebuffers and have the Intel GPU display
them. The only other plugin that is shipped is "linux-fallback" which
uses the fbdev interface instead. It is chosen by Surfman when no
compatible DRM device is found by the DRM plugin.

> Now, I do not understand the impact on security doing that. Are you still
> maintaining the isolation between the VMs?

Each guest will have a QEMU stdvga emulated card and will use that.
Surfman & plugins will get the drawn framebuffer from the emulated
card in QEMU and put it on screen.

> What about doing that with any GPU?

The current logic is using a modified Intel/DRM behavior in dom0 to
have the GPU scan the framebuffer from the emulation. This has
drawbacks, one of which being it is only usable on i915/DRM (Intel
integrated) devices.
There are other approaches and solutions to support a wider range of
graphics and talks during community calls have brought out Surfman's
limitations. There will likely have involvement to replace it for a
more flexible approach. Hopefully in a near future? :)

> But as I said, in my case, the Adapter+Mouse Switching preferences are not
> displayed in the UI. If that's what you're telling me.

Yes. That sounds like a bug. I believe this should be, starting in
UIVM upper-right "Settings", "Display", "Display Adapter" and "Mouse
Switching" tab.

> I found the explanation for the SELinux enforcement limiting the write
> access to the /storage folder. Once I deactivated it, everything worked.
> I questioning this design choice, especially when I see you can manage the
> permission for an "sys admin" and a "user".

Having a role, even optional, for image/disk management (access to
/storage & relevant) seems a valid suggestion to me.

> Yeah, hummm ... my question was more: what "xec set enable-dom0-networking
> true" does that "xec set enable-ssh true" does not, to enable SSH?

The first one should do what's necessary to get the PV interface in
dom0 accessible from the outside world (e.g. talk to the toolstack so
NDVM handle its backend). The second only starts sshd on that
interface.

> It is (clearly?) not possible to upload any kind of file through the UI,
> AFAIK... Did I miss a button or something?

I don't think you missed anything. This is done remotely through
syncui/vm, someone who is more familiar with these will have to shim
in though.

--
Eric CHANUDET

[Jean-Philippe Oudet]

From: Jean-Philippe Oudet <jp.o...@gmail.com>
Date: Tue, Mar 28, 2017 at 5:29 PM
Subject: Re: [openxt-dev] Install successful on EliteBook 8560w (v. 715), but what's next?
To: eric chanudet <eric.c...@gmail.com>

On Fri, Mar 24, 2017 at 10:50 AM, eric chanudet <eric.c...@gmail.com> wrote:

On Fri, Mar 24, 2017 at 9:53 AM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> On Thursday, March 23, 2017 at 12:29:27 PM UTC-4, Eric Chanudet wrote:
>> Surfman use fbdev copy plugin as a fallback (usual for Intel GPU
>> is drm-plugin).
> What's Surfman? The GUI? [Sorry, but I have a long way to go for the
> technicalities.]
My bad, I should have explained that further.
OpenXT uses a daemon called Surfman, in dom0, to display VMs on
screen. For legacy reasons, Surfman can use various plugins to handle
displaying through different means. The default plugin is "drm-plugin"
which uses the DRM API, the Intel sub-component of DRM (i915)
specifically, to create framebuffers and have the Intel GPU display
them. The only other plugin that is shipped is "linux-fallback" which
uses the fbdev interface instead. It is chosen by Surfman when no
compatible DRM device is found by the DRM plugin.

No problem, I can also do my homeworks ... but I do appreciate your help getting there faster.

I need to catch up on many fronts to understand the basis, so I'm progressing very slowly.

About that, I found this page: http://openxt.org/summit/. Is it possible to share the presentations? (And make it open/available to the public in the future?)

I see that I'm not the only one asking and some are even participating: https://groups.google.com/forum/#!msg/openxt/_jRMBm8xTZA/D3kVNyIoZpYJ.

I'll (try to) understand what's been done by M. Temkin. Is their any activity on this? Is he still active? His Github is 2 years old.

> Now, I do not understand the impact on security doing that. Are you still
> maintaining the isolation between the VMs?
Each guest will have a QEMU stdvga emulated card and will use that.
Surfman & plugins will get the drawn framebuffer from the emulated
card in QEMU and put it on screen.

Great.

So, Surfman is like a virtual "multiviewer"? He takes all the FB simultaneously, mix them (or pass each one sequentially when the "seamless" option is not enabled), and then push the result to the DRM/OGL stack. Am I correct?

I suppose the USB commands are also redirected from dom0.

 

> What about doing that with any GPU?
The current logic is using a modified Intel/DRM behavior in dom0 to
have the GPU scan the framebuffer from the emulation. This has
drawbacks, one of which being it is only usable on i915/DRM (Intel
integrated) devices.
There are other approaches and solutions to support a wider range of
graphics and talks during community calls have brought out Surfman's
limitations. There will likely have involvement to replace it for a
more flexible approach. Hopefully in a near future? :)

Yeahhhhhh!!! ;-)

To continue the discussion, I was looking at the current offerings in the market. 

• Most of the "new" laptops offered today are based on the i7-7500U (a few on a -HQ version). From ARK, those CPU do NOT have vPro, or TXT : https://ark.intel.com/products/95451/Intel-Core-i7-7500U-Processor-4M-Cache-up-to-3_50-GHz- and LOTS of them have a Nvidia card (a few have AMD GPUs).
  
  
• If TXT is really a must (as I understand you can make it work on a non-vPro CPU?), that let only the i7-7600 and up (or the Kaby-Lake-Y models, but those are power limited, tablet-like performances, CPU). And those are usually coming with a GeForce 930MX GPU (http://www.dell.com/us/partner/p/latitude-14-5480-laptop/pd).
  Yes, I know this one is new so I can go back to the 6th gen CPU. My point is as of today, laptops equipped with TXT enabled CPU are VERY rare. Not even one vPro model is present at Best Buy!
  The good news is that we have a good/powerful integrated GPU for OXT, and possibly another good one for one of the VM for top of the line systems. [The bad news is it costs 5k$! A bit more and we would be better with a Toughbook/Getac!]
  
  
• Xeon CPU are more and more present in those laptop, and would be valuable for virtualisation. But they do not have an Intel GPU.
  So only AMD/Nvidia GPU will be available.
  
  
• The i5-7440HQ looks ok, though. Much less expensive, still relatively powerful. Usually no discreet GPU.
  
  
• Last concern: for each of those models, will we be able to pass the discreet GPU to a VM, while using the integrated one for the others?
  They sell the discreet GPU not as options, but as a replacement (as I understood after the few hours of shopping I did). So, maybe they are just disabling the integrated GPU to use an external one, like they've done in this laptop (EliteBook 8560w).
  

My point here is that I believe OpenXT would benefit a lot in supporting Nvidia GPU as the main component, sooner than later.

I do not know the content of your past discussions. I'm just trying to understand the impact of the hardware on the display capabilities of OpenXT, especially with regards to the secure isolation of the displayed content.

> But as I said, in my case, the Adapter+Mouse Switching preferences are not
> displayed in the UI. If that's what you're telling me.
Yes. That sounds like a bug. I believe this should be, starting in
UIVM upper-right "Settings", "Display", "Display Adapter" and "Mouse
Switching" tab.

Nothing below "Screen Lock" (Settings/Display)!

Could be related to the lack of support for Nvidia GPU?

I have a lot of other problems too: 

• Debian (Jessie) stuck at a black screen, no means to open a console.
  Tried nomodeset during install. No luck.
  Is it possible to bochs_drm is doing that?
• Win8.1 not installing completely the XT-tools. Then ... reports the toolset is not up-to-date. And I've a Tool CD version 16.0.0.405 (still build 729) reported in OpenXT, but 16.0.0.42 reported by the VM.
  
• Win8.1 crashing on the NIC drivers (xensomething-related-a-virtual-NIC)

I'm dowloading other distributions to try them.

 

> I found the explanation for the SELinux enforcement limiting the write
> access to the /storage folder. Once I deactivated it, everything worked.
> I questioning this design choice, especially when I see you can manage the
> permission for an "sys admin" and a "user".
Having a role, even optional, for image/disk management (access to
/storage & relevant) seems a valid suggestion to me.

Excellent!

 

> Yeah, hummm ... my question was more: what "xec set enable-dom0-networking
> true" does that "xec set enable-ssh true" does not, to enable SSH?
The first one should do what's necessary to get the PV interface in
dom0 accessible from the outside world (e.g. talk to the toolstack so
NDVM handle its backend). The second only starts sshd on that
interface.

So, probably in my case, I opened the network and sshd was already running. Then the second command did nothing more.

I'll keep up with my readings.

> It is (clearly?) not possible to upload any kind of file through the UI,
> AFAIK... Did I miss a button or something?
I don't think you missed anything. This is done remotely through
syncui/vm, someone who is more familiar with these will have to shim
in though.

Noted. Would be nice though.

 

--
Eric CHANUDET

Thanks for the help.

[eric chanudet]

On Thu, Mar 30, 2017 at 5:09 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> About that, I found this page: http://openxt.org/summit/. Is it possible to
> share the presentations? (And make it open/available to the public in the
> future?)

I could not find them anywhere. Rich do you know if that has been made
available?

> So, Surfman is like a virtual "multiviewer"? He takes all the FB
> simultaneously, mix them (or pass each one sequentially when the "seamless"
> option is not enabled), and then push the result to the DRM/OGL stack. Am I
> correct?

Surfman with drm-plugin points the Intel graphic card to the pages
where the guest framebuffer is and configures it to scan the expected
geometry. So only one guest on the shared screen at a time,
multi-screen being only achieved by passing-through another GPU to a
guest.

> I suppose the USB commands are also redirected from dom0.

Yes, vusb-daemon in dom0 will use udev to be notified of new devices.
Then when asked to, it will load the vusb backend driver for the
requested device and do PV backend to frontend. Someone who worked on
the back/frontend could do a more detailed explanation I am sure.

> If TXT is really a must (as I understand you can make it work on a non-vPro
> CPU?)

VT-d is required, TXT can be disabled if you do not intend to do measurement.

> Last concern: for each of those models, will we be able to pass the discreet
> GPU to a VM, while using the integrated one for the others?

If I understand correctly, it should be ok ;), minus possible pending
issues with PCI GPU pass-through.

> I have a lot of other problems too:
> Debian (Jessie) stuck at a black screen, no means to open a console.
> Tried nomodeset during install. No luck.

Have you tried adding acpi=off to the kernel cmdline? There was a
known bug... OXT-808 if I am correct.

> Is it possible to bochs_drm is doing that?

Yes. The DISPI implementation on OpenXT QEMU is incomplete I believe,
which triggers an error with bochs_drm. I seem to remember there is a
ticket about that, although there was a work-around? I will have a
look...

--
Eric CHANUDET

[Jean-Philippe Oudet]

On Monday, April 3, 2017 at 6:04:32 PM UTC-4, Eric Chanudet wrote:

On Thu, Mar 30, 2017 at 5:09 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:
> About that, I found this page: http://openxt.org/summit/. Is it possible to
> share the presentations? (And make it open/available to the public in the
> future?)
I could not find them anywhere. Rich do you know if that has been made
available?

 Rich Persaud?

That would be great for newcomers to understand the architecture without having to look into the code.

Pretty please? ;-)

> So, Surfman is like a virtual "multiviewer"? He takes all the FB
> simultaneously, mix them (or pass each one sequentially when the "seamless"
> option is not enabled), and then push the result to the DRM/OGL stack. Am I
> correct?
Surfman with drm-plugin points the Intel graphic card to the pages
where the guest framebuffer is and configures it to scan the expected
geometry. So only one guest on the shared screen at a time,
multi-screen being only achieved by passing-through another GPU to a
guest.

Got it. I think.

Looks like some issues I have seems related to the drivers/non-Intel GPU.

 

> I suppose the USB commands are also redirected from dom0.
Yes, vusb-daemon in dom0 will use udev to be notified of new devices.
Then when asked to, it will load the vusb backend driver for the
requested device and do PV backend to frontend. Someone who worked on
the back/frontend could do a more detailed explanation I am sure.

I'll stat with that. Every seems to work fine for now (apart, perhaps when I did not have the hand on the Debian VM?? Maybe.) 

> If TXT is really a must (as I understand you can make it work on a non-vPro
> CPU?)
VT-d is required, TXT can be disabled if you do not intend to do measurement.

Ok, so mandatory for me (and for the core benefiits that OpenXT provides).

 

> Last concern: for each of those models, will we be able to pass the discreet
> GPU to a VM, while using the integrated one for the others?
If I understand correctly, it should be ok ;), minus possible pending
issues with PCI GPU pass-through.

Ideally, I would try that on a new platform, and figure out what is possible. (I just see now what's the limitations.)

This comment is to clarify the intent of the community, wrt to the future platform available. If the market provides only integrated Intel GPU versus dedicated Nvidia GPU, I believe you should be all aware of that and communicate effectively to others. Expectations managment, you know?

To be clear: for a 3 year old product dedicated to security, you have build a nice solution!

 

> I have a lot of other problems too:
> Debian (Jessie) stuck at a black screen, no means to open a console.
> Tried nomodeset during install. No luck.
Have you tried adding acpi=off to the kernel cmdline? There was a
known bug... OXT-808 if I am correct.

Yes, I saw that. But it wasn't the cause.

I managed to install fully an up-to-date Debian, with the Tools correctly installed and detected. But I forgot what was the problem. I remember having troubles with the bochs_drm deactivation, and ... permissions? Not sure.

Also, Linuxes install are not easy, because it take only the half left of the screen, with the content warped. So it difficult to read. But that's certainely related to the driver. After that, I can have the VM in full screen, good resolution. But I did not validate the Nvidia GPU is seen (probably not, since it is taken over by OpenXT and replaced by its virtual GPU).

Now, I tried to install Windows 8.1 Pro. No luck with the Tools. I added the certificates, that helped. But even with them, installed as an Admin, and with all my devotion and googling, I failed. The VM is up and running, but the tools are not recognized by OpenXT.

Any advices?

I'll delete and retry the complete install another time, see if that's help.

 

> Is it possible to bochs_drm is doing that?
Yes. The DISPI implementation on OpenXT QEMU is incomplete I believe,
which triggers an error with bochs_drm. I seem to remember there is a
ticket about that, although there was a work-around? I will have a
look...

Oh boy, I need schematics and boxes/arrows diagrams ... ;-)

For the driver, I can validate that helps. So, still a valid concern. But it seems this is already discussed in this group. I'll try to keep up with what you're doing, then.

Thanks Éric!

--
Eric CHANUDET

[Rich Persaud]

On Apr 3, 2017, at 18:04, eric chanudet <eric.c...@gmail.com> wrote:

On Thu, Mar 30, 2017 at 5:09 PM, Jean-Philippe Oudet <jp.o...@gmail.com> wrote:

About that, I found this page: http://openxt.org/summit/. Is it possible to

share the presentations? (And make it open/available to the public in the

future?)

I could not find them anywhere. Rich do you know if that has been made
available?

https://groups.google.com/forum/m/#!topic/openxt/s_7HJ-dVfsw

For an overview of OpenXT, see the Xen Summit 2016 presentation:

Video:  https://youtube.com/watch?v=nP-j_4K0T_0

Slides:  https://www.slideshare.net/mobile/xen_com_mgr/the-openxt-project-in-2016-christopher-clark-bae-systems

Rich

[Ross Philipson]

Having to use acpi=off was because of a bug in the _LID ACPI device in the guest virtual firmware. That has been fixed in the master and stable-6 branches.

 

Also, Linuxes install are not easy, because it take only the half left of the screen, with the content warped. So it difficult to read. But that's certainely related to the driver. After that, I can have the VM in full screen, good resolution. But I did not validate the Nvidia GPU is seen (probably not, since it is taken over by OpenXT and replaced by its virtual GPU).

Now, I tried to install Windows 8.1 Pro. No luck with the Tools. I added the certificates, that helped. But even with them, installed as an Admin, and with all my devotion and googling, I failed. The VM is up and running, but the tools are not recognized by OpenXT.

Any advices?

That is really strange. I assume you enabled test signing and added the certs to the store per the instructions? Is there anything in the setup.api log that indicates what went wrong?

 

I'll delete and retry the complete install another time, see if that's help.

 

> Is it possible to bochs_drm is doing that?
Yes. The DISPI implementation on OpenXT QEMU is incomplete I believe,
which triggers an error with bochs_drm. I seem to remember there is a
ticket about that, although there was a work-around? I will have a
look...

Oh boy, I need schematics and boxes/arrows diagrams ... ;-)

For the driver, I can validate that helps. So, still a valid concern. But it seems this is already discussed in this group. I'll try to keep up with what you're doing, then.

The bochs_drm thing is still a problem. I have a fix in mind but have not implemented it yet. The work around instructions are in the 6.0.0 release notes:

https://github.com/OpenXT/docs/tree/master/releases