Windows 10 Enterprise-64bit install

[catalinbostan]

• SmartOS Live Image v0.147+ build: 20160707T032945Z -SW_DVD5_WIN_ENT_10_1511.2_64BIT_English_MLF_X20-99544.ISO CPU:2 x X5680

with cpu_type": "guest" or "qemu64" i have old "ip_Interface_cleanup: cannot open /devices/pseudo/udp6@0:udp6: error 13"

Solution: vmadm update UUID cpu_type=core2duo

[rmustacc]

On 7/8/16 23:30 , catalinbostan wrote:

• SmartOS Live Image v0.147+ build: 20160707T032945Z -SW_DVD5_WIN_ENT_10_1511.2_64BIT_English_MLF_X20-99544.ISO CPU:2 x X5680

with cpu_type": "guest" or "qemu64" i have old "ip_Interface_cleanup: cannot open /devices/pseudo/udp6@0:udp6: error 13"

Solution: vmadm update UUID cpu_type=core2duo

Can you clarify about what was erroring? Was the system refusing to start? Was Windows panicking? Thanks!

[catalinbostan]

Installer start but hang (withour error messages) forever at first step after "loading windows" from iso.Just "ip_Interface_cleanup: cannot open /devices/pseudo/udp6@0:udp6: error 13" in vm log. I'll test same configuration under linux kvm, with the same installer when i have time, but until now i was able to install and run properly with cpu_type=core2duo.I'll try today to test with different cpu_type=nehalem and keep you posted.I'll try also to change cpu_type to guest and qemu64 on a installed vm to test if my guess about windows HAL improperly recognizing CPU is valid.Right now with cpu_type=core2duo, Windows 10 see T7700 cpu on device manager.

[ghost]

@rmustacc My experience has been with Server 2016, which shares a lot with Windows 10;

It seems like whatever the default cpu_type is causes Windows 10/2016 to fail to boot - at least on the box I've been testing with so far. The OS appears to hang directly after the bootloader has done it's thing - not sure if enough of Windows has been loaded at this point to cause a panic, so no BSOD is seen.

If, however, cpu_type is changed to host, the OS will boot and install without issue.

I'd always assumed (ass-u-me?) that cpu_type would be set to host if it wasn't specified in the zone configuration. If this isn't the case, what does cpu_type default to?

cpu_type not set

cpu_type=host

If it's any use, this particular machine (which I use for making KVM images);

# sysinfo
{
  "Live Image": "20170105T024017Z",
  "System Type": "SunOS",
  "Boot Time": "1484746601",
  "SDC Version": "7.0",
  "Manufacturer": "",
  "Product": "",
  "Serial Number": "",
  "SKU Number": "To be filled by O.E.M.",
  "HW Version": "",
  "HW Family": "To be filled by O.E.M.",
  "Setup": "false",
  "VM Capable": true,
  "CPU Type": "Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz",
  "CPU Virtualization": "vmx",
  "CPU Physical Cores": 1,
  "UUID": "a9d84f0a-8af7-11e1-8de7-000ea62c9f8e",
  "Hostname": "build",
  "CPU Total Cores": 4,
  "MiB of Memory": "8090",
  "Zpool": "zones",
  "Zpool Disks": "c1t0d0,c1t1d0",
  "Zpool Profile": "mirror",
  "Zpool Creation": 1481889993,
  "Zpool Size in GiB": 1798,
  "Disks": {
    "c1t0d0": {"Size in GB": 2000},
    "c1t1d0": {"Size in GB": 2000},
    "c1t2d0": {"Size in GB": 32}
  },
  "Boot Parameters": {
    "console": "vga",
    "vga_mode": "115200,8,n,1,-",
    "root_shadow": "HOWABOUTNO?",
    "smartos": "true"
  },
  "Network Interfaces": {
    "e1000g0": {"MAC Address": "x:x:x:x:x:x", "ip4addr": "x.x.x.x", "Link Status": "up", "NIC Names": ["admin"]}
  },
  "Virtual Network Interfaces": {
  },
  "Link Aggregations": {
  }
}

Can test out on a SMCI Xeon box if needs be!

[ghost]

Defaults to qemu64, so there must be a feature that Windows 10/2016 needs either missing or not enabled in the qemu64 emulated CPU.

[ghost]

https://bugzilla.redhat.com/show_bug.cgi?id=1346153#c31 May be of interest;

The problem with cpu type qemu64 is that it doesn't provide +fsgsbase flag by default.