Win 10 VM Will no Longer Start

[comfox]

Hi All,

 

I upgraded to 6.2.1 this morning and once booted up my VM would not start.  I downgraded back to 6.2 and it still won't start so creating this thread for help.

 

Here is the error from the VM page.

 

2016-10-07 14:05:01.388+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Tower
Domain id=1 is tainted: high-privileges
Domain id=1 is tainted: custom-argv
Domain id=1 is tainted: host-cpu
char device redirected to /dev/pts/0 (label charserial0)
2016-10-07T14:05:02.215662Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/16: Operation not permitted
2016-10-07T14:05:02.215685Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 16
2016-10-07T14:05:02.215690Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed
2016-10-07 14:05:02.481+0000: shutting down
2016-10-07 14:07:02.947+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Tower
Domain id=2 is tainted: high-privileges
Domain id=2 is tainted: custom-argv
Domain id=2 is tainted: host-cpu
char device redirected to /dev/pts/0 (label charserial0)
2016-10-07T14:07:03.762923Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/16: Operation not permitted
2016-10-07T14:07:03.762947Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 16
2016-10-07T14:07:03.762952Z qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed
2016-10-07 14:07:04.033+0000: shutting down

 

I believe it is erroring out on my Video Card, but really have no idea what to change to make it work.  Worked fine in all 6.2 and lower versions, and now doesn't.

 

Here is my list of PCI Devices

 

00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
00:01.1 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller [8086:0c05] (rev 06)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d5)
00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 [8086:8c16] (rev d5)
00:1c.5 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 [8086:8c1a] (rev d5)
00:1c.6 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #7 [8086:8c1c] (rev d5)
00:1c.7 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #8 [8086:8c1e] (rev d5)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
00:1f.0 ISA bridge [0601]: Intel Corporation Z87 Express LPC Controller [8086:8c44] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)
02:00.0 USB controller [0c03]: Fresco Logic FL1100 USB 3.0 Host Controller [1b73:1100] (rev 10)
04:00.0 Ethernet controller [0200]: Qualcomm Atheros Killer E220x Gigabit Ethernet Controller [1969:e091] (rev 13)
05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge [12d8:e111] (rev 02)
06:04.0 RAID bus controller [0104]: Silicon Image, Inc. SiI 3124 PCI-X Serial ATA Controller [1095:3124] (rev 01)
07:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
08:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 01)

 

Here is the IOMMU Groups

 

/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:01.1
/sys/kernel/iommu_groups/3/devices/0000:00:02.0
/sys/kernel/iommu_groups/4/devices/0000:00:03.0
/sys/kernel/iommu_groups/5/devices/0000:00:14.0
/sys/kernel/iommu_groups/6/devices/0000:00:16.0
/sys/kernel/iommu_groups/7/devices/0000:00:1a.0
/sys/kernel/iommu_groups/8/devices/0000:00:1b.0
/sys/kernel/iommu_groups/9/devices/0000:00:1c.0
/sys/kernel/iommu_groups/10/devices/0000:00:1c.3
/sys/kernel/iommu_groups/11/devices/0000:00:1c.5
/sys/kernel/iommu_groups/12/devices/0000:00:1c.6
/sys/kernel/iommu_groups/13/devices/0000:00:1c.7
/sys/kernel/iommu_groups/14/devices/0000:00:1d.0
/sys/kernel/iommu_groups/15/devices/0000:00:1f.0
/sys/kernel/iommu_groups/15/devices/0000:00:1f.2
/sys/kernel/iommu_groups/15/devices/0000:00:1f.3
/sys/kernel/iommu_groups/16/devices/0000:01:00.0
/sys/kernel/iommu_groups/16/devices/0000:01:00.1
/sys/kernel/iommu_groups/17/devices/0000:02:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/19/devices/0000:05:00.0
/sys/kernel/iommu_groups/19/devices/0000:06:04.0
/sys/kernel/iommu_groups/20/devices/0000:07:00.0
/sys/kernel/iommu_groups/21/devices/0000:08:00.0

 

Here is my VM XML

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <name>Win 10 Main PC</name>
  <uuid>e43d49b3-00c0-a740-1250-341a6f1f11a4</uuid>
  <description>This is the main gaming rig in the office</description>
  <metadata/>
  <memory unit='KiB'>12107200</memory>
  <currentMemory unit='KiB'>12107200</currentMemory>
  <memoryBacking>
    <nosharepages/>
    <locked/>
  </memoryBacking>
  <vcpu placement='static'>7</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='1'/>
    <vcpupin vcpu='1' cpuset='2'/>
    <vcpupin vcpu='2' cpuset='3'/>
    <vcpupin vcpu='3' cpuset='4'/>
    <vcpupin vcpu='4' cpuset='5'/>
    <vcpupin vcpu='5' cpuset='6'/>
    <vcpupin vcpu='6' cpuset='7'/>
  </cputune>
  <os>
    <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
      <spinlocks state='on' retries='8191'/>
      <vendor id='none'/>
    </hyperv>
  </features>
  <cpu mode='host-passthrough'>
    <topology sockets='1' cores='7' threads='1'/>
  </cpu>
  <clock offset='localtime'>
    <timer name='hypervclock' present='yes'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='writeback'/>
      <source file='/mnt/user/VM_HDD_Lib/Win 10 Main PC/vdisk1.img'/>
      <target dev='hdc' bus='virtio'/>
      <boot order='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='nec-xhci'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:d9:23:a0'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <source mode='bind'/>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x1532'/>
        <product id='0x011a'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='yes'>
      <source>
        <vendor id='0x046d'/>
        <product id='0xc24a'/>
      </source>
    </hostdev>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <driver name='vfio'/>
      <source>
        <address domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
      </source>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </hostdev>
    <hostdev mode='subsystem' type='usb' managed='no'>
      <source>
        <vendor id='0x2433'/>
        <product id='0xb200'/>
      </source>
    </hostdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
  </qemu:commandline>
</domain>

 

For some reason my unRAID will not download an Anonymous version of diagnostics (clicking the button and nothing happens) so I can't post that.  I have posted my syslog though.

syslog.txt

[bungee91]

Please provide the listing of your IOMMU groups, you'll find this listed in the system devices page.

 

It looks as if for whatever reason the device 1:00:0 is now in a group with other devices, which would give this error.

This is speculation until I see that output.

 

 

[comfox]

Please provide the listing of your IOMMU groups, you'll find this listed in the system devices page.

 

It looks as if for whatever reason the device 1:00:0 is now in a group with other devices, which would give this error.

This is speculation until I see that output.

 

Yes of course, I thought I had put that in, guess I copied and didn't paste it.  See above.

[bungee91]

My theory was incorrect (but was the most likely thing).

I don't use the PCI ACS override, but it does appear to be working if/as needed, as your groups are separated.

 

I'm kind of wondering if something is binding this card, preventing it to be assigned to vfio-pci.

From the terminal if you type "lspci -v" look and see if the device is binded to something.

 

It should look like this example (this is a USB card of mine), however not have the binded line at the bottom, should be free for the VM start to grab/bind as needed:

0e:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI])
        Flags: bus master, fast devsel, latency 0, IRQ 18, NUMA node 0
        Memory at fb500000 (64-bit, non-prefetchable) [size=64K]
        Memory at fb510000 (64-bit, non-prefetchable) [size=8K]
        Capabilities: [40] Power Management version 3
        Capabilities: [48] MSI: Enable- Count=1/8 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 00
        Capabilities: [c0] MSI-X: Enable+ Count=8 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [150] Device Serial Number 08-00-28-00-00-20-00-00
        Kernel driver in use: vfio-pci

 

[andrewraynor]

i am on 6.2 and was thinking of upgrading but reading this i am worried. will upgrading to the 6.2.1 or 6.3 rc be likely to change iommu groups

for anyone who uses acs override?

[comfox]

My theory was incorrect (but was the most likely thing).

I don't use the PCI ACS override, but it does appear to be working if/as needed, as your groups are separated.

 

I'm kind of wondering if something is binding this card, preventing it to be assigned to vfio-pci.

From the terminal if you type "lspci -v" look and see if the device is binded to something.

 

...

 

Thanks.  After a fresh boot up here is the output of the command for the Group 16 IOMMU

 

01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. GM204 [GeForce GTX 970]
        Flags: fast devsel, IRQ 11
        Memory at f6000000 (32-bit, non-prefetchable) [disabled] [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [disabled] [size=256M]
        Memory at f0000000 (64-bit, prefetchable) [disabled] [size=32M]
        I/O ports at e000 [disabled] [size=128]
        Expansion ROM at f7000000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [250] Latency Tolerance Reporting
        Capabilities: [258] L1 PM Substates
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Capabilities: [900] #19

01:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1)
        Subsystem: ASUSTeK Computer Inc. GM204 High Definition Audio Controller
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at f7080000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Endpoint, MSI 00

[comfox]

I just tried to start up the VM again, it failed, and the output of that command has changed.  This is now what it shows:

 

01:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. GM204 [GeForce GTX 970]
        Flags: fast devsel, IRQ 11
        Memory at f6000000 (32-bit, non-prefetchable) [disabled] [size=16M]
        Memory at e0000000 (64-bit, prefetchable) [disabled] [size=256M]
        Memory at f0000000 (64-bit, prefetchable) [disabled] [size=32M]
        I/O ports at e000 [disabled] [size=128]
        Expansion ROM at f7000000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Legacy Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [250] Latency Tolerance Reporting
        Capabilities: [258] L1 PM Substates
        Capabilities: [128] Power Budgeting <?>
        Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Capabilities: [900] #19
        Kernel driver in use: vfio-pci

01:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1)
        Subsystem: ASUSTeK Computer Inc. GM204 High Definition Audio Controller
        Flags: bus master, fast devsel, latency 0, IRQ 10
        Memory at f7080000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [60] Power Management version 3
        Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Express Endpoint, MSI 00
        Kernel driver in use: vfio-pci

[bungee91]

The device certainly looks as if it should be able to be assigned, not certain why you're getting this issue, sorry.

Hopefully someone else will have some input, as it doesn't seem to be an obvious issue.

[kode54]

They don't have ACS on root ports, yet they are using the ACS override, which is attempting to break up the video card from its root port(s). They need to kill that kernel option, reboot, and plan their IOMMU adventures properly for the hardware they have.

[bungee91]

They don't have ACS on root ports, yet they are using the ACS override, which is attempting to break up the video card from its root port(s). They need to kill that kernel option, reboot, and plan their IOMMU adventures properly for the hardware they have.

 

This is incorrect, and I do fully understand the lack of isolation, the non upstream patch being used, and what is being reported here.

The fact that the outputs show the grouping being separated allows for this to be functioning, even though true isolation is not achieved.

However this patch works for many (read: a lot of people here), for allowing for a device to be assigned to a VM.

Since the outputs show that the device is assignable (IE: not in a group with other devices, regardless if direct DMA could cause issues/corruption) should not be relevant to the fact that the VM will not start. Something else is a muck here, but it is not common.

While I do not recommend the ACS override patch (nor do most in the community, and hence the warnings it prompts), it is effective for many in allowing for devices to be assigned assuming isolation when there is no hardware in place to actually provide it. Regardless, the device should be assignable and allow for this VM to start.

[kode54]

I simply assumed from searching and finding that ACS functionality only exists in Core Extreme and Xeon parts meant that the ACS override feature would be broken on anything less than those configurations.

 

I, too, experienced this issue attempting to bind my PCIe video cards when I had ACS override enabled, or at least failed to separate my second video card from the first one.

 

If it really matters, I can try rebooting with ACS override enabled, and see if my Windows VM will even boot without manually binding the PCIe root that is normally coupled with it.

[bungee91]

It is possible that the override is not working correctly, however reporting that the devices are in separate groups, causing this to fail.

You're correct that ACS on root ports is only available (at this time) on the "E" edition i7's, and the E5 Xeon's.

I'm going to assume that the OP requires this to be enabled, or the device he is trying to pass is grouped with other devices.

It is always recommended to attempt to relocate the device, and hopefully it is moved into a group by itself, which would then have actual isolation and not require this patch.

 

Since you mentioned the override failed to separate your 2nd video card from your first one, I'd say the patch wasn't working as it is intended to for your hardware.

However in this case the output(s) look like it is, just unfortunately not working when starting the VM.

Unfortunately none of this is helping the OP, so hopefully someone can chime in with some additional help.

I suppose you could try to stub the device ID and see if it helps, however being that the output shows it is free, or being bound to vfio-pci, I wouldn't think this would help solve your issue.

[comfox]

Just updating everyone that has helped me on this issue so far...

 

Since it was a holiday weekend where I am, I decided to build a new VM from scratch using a bunch of the new features that 6.2 offered (pci stubbing, gui assinging of devices, etc, etc) as my old VM was over a year old and from the original days of KVM's on unRAID.  This also allowed me to install Win 10 Anniversary Update since my old VM would error out when trying.

 

The newly built VM is up and running just fine and I migrated all my data off of the old VM by assigning the img as disk 2 and doing a straight copy.  This VM has been running for 24 hours now and is working fine.  All devices are passed through and it is performing as expected.

 

I know this is the most drastic option for resolving this issue but non the less it has resolved the issue.  Feel free to move on from this post and enjoy your day!

[jonp]

Just updating everyone that has helped me on this issue so far...

 

Since it was a holiday weekend where I am, I decided to build a new VM from scratch using a bunch of the new features that 6.2 offered (pci stubbing, gui assinging of devices, etc, etc) as my old VM was over a year old and from the original days of KVM's on unRAID.  This also allowed me to install Win 10 Anniversary Update since my old VM would error out when trying.

 

The newly built VM is up and running just fine and I migrated all my data off of the old VM by assigning the img as disk 2 and doing a straight copy.  This VM has been running for 24 hours now and is working fine.  All devices are passed through and it is performing as expected.

 

I know this is the most drastic option for resolving this issue but non the less it has resolved the issue.  Feel free to move on from this post and enjoy your day!

 

Before 6.2.1, were you running 6.2.0 or an earlier version?

[comfox]

Just updating everyone that has helped me on this issue so far...

 

Since it was a holiday weekend where I am, I decided to build a new VM from scratch using a bunch of the new features that 6.2 offered (pci stubbing, gui assinging of devices, etc, etc) as my old VM was over a year old and from the original days of KVM's on unRAID.  This also allowed me to install Win 10 Anniversary Update since my old VM would error out when trying.

 

The newly built VM is up and running just fine and I migrated all my data off of the old VM by assigning the img as disk 2 and doing a straight copy.  This VM has been running for 24 hours now and is working fine.  All devices are passed through and it is performing as expected.

 

I know this is the most drastic option for resolving this issue but non the less it has resolved the issue.  Feel free to move on from this post and enjoy your day!

 

Before 6.2.1, were you running 6.2.0 or an earlier version?

 

I was running 6.2.0 for 2 days prior to upgrading to 6.2.1.  All was working fine on 6.2.0 prior to the upgrade to 6.2.1

[jonp]

Ok, your problem was that you left some old XML code in there that didn't apply in 6.2 and above.  I'm guessing you missed the part in the announcement post about applying a save to your VM before starting it in 6.2 first.  Its surprising that it even working in 6.2.0.  Either way, I'm just glad you're back to a working state.

[comfox]

Ok, your problem was that you left some old XML code in there that didn't apply in 6.2 and above.  I'm guessing you missed the part in the announcement post about applying a save to your VM before starting it in 6.2 first.  Its surprising that it even working in 6.2.0.  Either way, I'm just glad you're back to a working state.

 

Yes your guess is correct.  I did not see that part in the announcement nor did I do that Save process.  I expressed my displeasure about the update process in another thread and this process reiterates that.  I did the upgrade from the Add On page and there was no mention of reading the announcement nor having to do anything more then simply "REBOOT REQUIRED".  The upgrade process should either be taken out of the Add On section OR that section be amped up considerably to provide a lot more information on what to do with an update.

 

Just two cents from a frustrated two pro license customer!

[jonp]

Ok, your problem was that you left some old XML code in there that didn't apply in 6.2 and above.  I'm guessing you missed the part in the announcement post about applying a save to your VM before starting it in 6.2 first.  Its surprising that it even working in 6.2.0.  Either way, I'm just glad you're back to a working state.

 

Yes your guess is correct.  I did not see that part in the announcement nor did I do that Save process.  I expressed my displeasure about the update process in another thread and this process reiterates that.  I did the upgrade from the Add On page and there was no mention of reading the announcement nor having to do anything more then simply "REBOOT REQUIRED".  The upgrade process should either be taken out of the Add On section OR that section be amped up considerably to provide a lot more information on what to do with an update.

 

Just two cents from a frustrated two pro license customer!

 

Agreed.  It would be ideal if we could make it so that when extra steps are required in an upgrade process, that those steps are somehow highlighted to you before you can apply the upgrade (as a function within our webGui).  It is something we will look into in the future, but for now, just know that anytime you see an OS upgrade option available, you should check the announcement forum to see if there are special steps required to be performed for the upgrade to work properly.  Not an ideal solution, but Rome wasn't built in a day ;-)