Server will not shut down
-
Hi All,
Got an oddball problem here... We are working on setting up several VM clones for a project here. Each VM will be connected to the same shared storage via iSCSI.
So we install our base OS, get everything configured, snapshotted and sysprepped.
The VMs are running Server 2012 R2, have 4 vCPU, 8GB of RAM, and 120GB of HDD, and 2 x NICs (using the E1000E drivers).
So now on the cloned systems, they boot up, and run painfully slow. And then when we tell them to reboot, they actually will sit there and never reboot, but they'll be stuck at "Restarting", like it's about to reboot... but it never does.
Anybody have any ideas that I can check?
-
My guess would be a service inside of the VM is hung / waiting to stop.
I've had a few cases of physical and virtual systems taking forever to reboot, and it's always been a service related issue.
Is anything installed to these systems? I've also had VM's run painfully slow because of shared resources (printers specifically) trying to be installed.
-
No, we don't have anything running on them yet. The iSCSI initiator service is the only thing that has been set up, and our usual disable IEC, and UAC type stuff.
Otherwise, it is a basic Server 2012 R2 install.
-
This probably has nothing to do with it, but how is the shared storage configured? Are there multiple I/O paths, or is there a single partitioned share that could bottleneck access to the storage?
-
Hrm, how did you create the clones?
SAN IOPS still solid?
That's a lot of CPU for VM machines, are you getting scheduling conflicts with processor time?
Those were the first things I thought of at least.
-
@art_of_shred said in Server will not shut down:
This probably has nothing to do with it, but how is the shared storage configured? Are there multiple I/O paths, or is there a single partitioned share that could bottleneck access to the storage?
There are multiple storage paths. Each NIC in the VM connects to a different physical NIC in the VMware host.
-
Could it be that I need to manually set the interface metric -- to force one to always be master?
-
Hrm. . .
Are you using the RDP connection option from within XenCenter to connect to these systems? (still investigating the shared resources item mentioned above.)
-
@DustinB3403 said in Server will not shut down:
Hrm. . .
Are you using the RDP connection option from within XenCenter to connect to these systems? (still investigating the shared resources item mentioned above.)
This is running on VMware.
We are connecting to them via RDP and the VMware console. Neither makes any difference.
-
@travisdh1 said in Server will not shut down:
Hrm, how did you create the clones?
SAN IOPS still solid?
That's a lot of CPU for VM machines, are you getting scheduling conflicts with processor time?
Those were the first things I thought of at least.
SAN IOPs are still good. We're barely even touching the SAN (this is a security camera system that's not in production yet).
-
@dafyre said in Server will not shut down:
@DustinB3403 said in Server will not shut down:
Hrm. . .
Are you using the RDP connection option from within XenCenter to connect to these systems? (still investigating the shared resources item mentioned above.)
This is running on VMware.
We are connecting to them via RDP and the VMware console. Neither makes any difference.
Yeah I realized I was a few minutes behind the ball after posting. So ignore me.
-
@dafyre said in Server will not shut down:
Got an oddball problem here... We are working on setting up several VM clones for a project here. Each VM will be connected to the same shared storage via iSCSI.
Under the hood, right? Via the datastore, not iSCSI connecting to the OS inside of the VM, right?
-
@dafyre said in Server will not shut down:
No, we don't have anything running on them yet. The iSCSI initiator service is the only thing that has been set up, and our usual disable IEC, and UAC type stuff.
Otherwise, it is a basic Server 2012 R2 install.
Why use iSCSI from inside of the VM?
-
Why 4 vCPU each? That seems excessive.
-
Given the setup, my inkling is that you have an issue with the iSCSI Initiator. The Microsoft iSCSI Initiator is known to be flaky and can easily be causing an issue. Both architecturally and practically due to the use of Windows it is standard practice to present SAN storage as a local drive via VMware to the VM rather than inside of the VM. VMware's handling of iSCSI is much more robust than Windows is, and you need only one connection per physical host rather than one per VM.
-
@JaredBusch said in Server will not shut down:
Why 4 vCPU each? That seems excessive.
Agreed. We don't expect the software to use that much, but we're building it to the specs that our vendor has requested.
-
@dafyre said in Server will not shut down:
@JaredBusch said in Server will not shut down:
Why 4 vCPU each? That seems excessive.
Agreed. We don't expect the software to use that much, but we're building it to the specs that our vendor has requested.
With virtualization that can cause performance problems. The vendor may be injecting a mistake here. Having more cores than are needed will degrade performance. And... can cause lockups in rare cases.
-
@scottalanmiller said in Server will not shut down:
@dafyre said in Server will not shut down:
No, we don't have anything running on them yet. The iSCSI initiator service is the only thing that has been set up, and our usual disable IEC, and UAC type stuff.
Otherwise, it is a basic Server 2012 R2 install.
Why use iSCSI from inside of the VM?
Because it works that way?
That's the way I would set it up. Although this time, I'm actually not the one who set up the master image. We're connecting to a SAN to store large amounts of video for security cameras.
-
@dafyre said in Server will not shut down:
Why use iSCSI from inside of the VM?
Because it works that way?
Well it doesn't work well that way and in this case, it's possible that it doesn't work at all
-
@dafyre said in Server will not shut down:
That's the way I would set it up. Although this time, I'm actually not the one who set up the master image. We're connecting to a SAN to store large amounts of video for security cameras.
I'm not questioning the SAN or the iSCSI. I'm questioning the configuration which is extremely complex and fragile compared to a more elegant, more modern configuration using VMware as designed.
