In order to take advantage of some XenServer features, you need to have a paravirtualization (PV) turned on for your guest host. You maybe running in HVM because you installed your operating system from a disk and not a XenServer created template. Now days xen is built into the linux kernel and we don’t need a special kernel installed. We just need to change the settings in XenServer to boot the system.
Note: I tested this on Ubuntu 14.04 and 16.04 with systems that already had XenTools installed. I’m assuming the procedure doesn’t change much to other distros.
Find the UUID of the guest host you want to convert from HVM to PV xe vm-list name-label=<name of guest host>
Print out the current parameters for the guest host and save them as a backup. xe vm-param-list uuid=<uuid from step 1>
Update parameters to boot your system as paravirtualization xe vm-param-set uuid=<uuid from step 1> HVM-boot-policy=""
xe vm-param-set uuid=<uuid from step 1> PV-bootloader=pygrub
xe vm-param-set uuid=<uuid from step 1> PV-args="-- quiet console=hvc0"
Find the UUID for your VDB boot disk xe vm-disk-list uuid=<uuid from step 1>
Set the drive as bootable xe vbd-param-set uuid=<uuid from step 4> bootable=true
Boot the system and review the console in XenCenter. If the system boots, BUT you don't get the login window, you may need to complete create this config file.
Create this file if it doesn't exist on your guest host: /etc/init/hvc0.conf
# hvc0 - getty
# This service maintains a getty on hvc0 from the point the system is
# started until it is shut down again.
start on stopped rc RUNLEVEL=
stop on runlevel [!2345]
I’ve been having issues attaching a VDI to a VM from a NetApp snapshot. Basically a storage level snapshot that happen while the server was live. I keep getting the error “The attempt to load the VDI failed” via XenCenter when I try and boot the VM. I would then look at the log file: /var/log/xensource.log. I would see that the VM was tossing out the error “SR_BACKEND_FAILURE_65” when it tried to boot.
I have been unable to get the VDI to load on any server. I even contacted Citrix looking for help and they were unable to get the VDI to load as well. I’ve seen several others on the internet run into this issue without a resolution. If someone knows of a trick to get these VDIs to load, please leave a comment!
Yesterday we started to run out of space on one of our storage repositories. When we tried to move any VDI on that SR via XenCenter, we got the error “The SR failed to complete the operation”. Which is a pretty generic error, par for xenserver errors. I even got the same error when trying to do a ‘Rescan’.
I continued to troubleshoot, looking through logs and command outputs. I finally found something to look into.
Ran the command (use the UUID of a SR you’re having issues with): xe sr-param-list uuid=eb943814-a329-5f84-bd42-af1858d56632
Noticed this parameter: other-config (MRW): dirty: ; auto-scan: false
I looked into this “dirty” param… It means xenserver isn’t happy with the file names on the SR. I listed the files on my SR and saw that someone created a copy of a VDI called: Copy of f897ebcf-9365-471b-8a30-e81f564c2536.vhd.
I fixed it by:
Found file that shouldn’t be here called Copy of f897ebcf-9365-471b-8a30-e81f564c2536.vhd
Removed the file Copy of f897ebcf-9365-471b-8a30-e81f564c2536.vhd
Rescanning the SR
I was then able to move the VDI from one SR to another with out error in xencenter.
Noticed this on the Citrix blog today. A nice little performance comparison between ESXi 5.5 and XenServer 6.5. Citrix claims to show a 11-16% performance advantage over VMware. I’m holding off on upgrading to 6.5 till summer, but can’t wait to run some of my own benchmarks against XenServer 6.2.
Xenserver 6.5 promises to provide more performance, more GPU access, and bring back Workload Balancing (WLB). I won’t be applying 6.5 for a few months, so please let me know of any experiences you have in the comments.
I was just getting caught up on some Citrix information and ran across this blog post. I’m happy to see they are addressing the concern of XenServer being dropped as a product once it was open sourced. And I’m glad to hear they will be moving it forward with some big changes I didn’t even know needed to happen. Like moving dom0 to 64-bit. When I read that, I had to jump on one of my 6.2 servers and do a quick `uname -a` to see if it was true! And sure enough, it’s kernel is compiled for i686.
Here are the official the preview release notes Citrix gave out:
Sometimes I’ll reboot a linux VM and I can see it went all the way down. The machine is off far as I can tell but never ends up rebooting. I then try doing a shutdown via XenCenter and I get error message: “VM didn’t acknowledge the need to shut down”.
I get so angry that the error tells me the VM didn’t ACKNOWLEDGE the NEED to shut down, really?? I, the administrator just told this piece of software to shutdown and it’s telling ME that it doesn’t acknowledge my command? Reminds of an old error message I saw in Windows 95/98, “Windows will manage these settings”. I think to myself, am I commanding the computer, or does the computer command me?
Pretty much this GIF explains everything I feel about this error.
This weekend I’ve updated from 6.1 to 6.2. Here are the steps I took to do the upgrade.
Make sure you have upgraded your licenses to 6.2 (May require login). They have changed to a per socket structure, for us we have two sockets per server, and was able to upgrade without paying extra. The upgrade will warning you if you don’t have the 6.2 license, but you can continue on… just make sure you’ve got the new 6.2 license is applied to your license server.
After a power outage we ran into some errors after bring everything back up. When trying to reconnect a CIFS share on our NetApp filer, we got the following errors.
Jan 3, 2014 10:40:10 AM Error: Repairing SR CIFS ISO library On Netapp - Unable to mount the directory specified in device configuration request
Jan 3, 2014 10:40:54 AM Error: Detaching SR 'CIFS ISO library On Netapp' from 'SOME POOL' - General backend error
At first I thought the issue was Xenserver not bring joined to the Active Directory domain. But I was wrong, the issue was the NetApp wasn’t joined to the AD domain. So make sure everyone is on the domain and you may get rid of these errors. For us, the issue was the time on the NetApp was off by 6 minutes and was causing errors when trying to join AD (time needs to be with in sync within 5 minutes).