Remove:
- xe vm-list
- Copy the uuid for the VM you want to remove the interface.
- xe vif-list vm-uuid=<vm-uuid>
- Copy the uuid for the vif you want to destroy.
- xe vif-destroy uuid=<vif-uuid>
Note you will need to know which device you want to remove if there is more than one interface attached to the VM.
Add:
- xe list-network (you can add "name-label=<label>" if you know the networks name, in my case Bond 0+1)
- Copy the networks uuid.
- xe vif-create network-uuid=<network-uuid> vm-uuid=<vm-uuid> device=#
See above for how to find the VM's uuid, for device replace # with the device number, you can find a list of supported VIF devices by typing "xe vm-param-list uuid=<vm-uuid> | more" and looking for allowed-VIF-devices, if theres no interface currently on the VM you will most likely use 0.
As for why you would want to do all of this...well, sometimes you either don't have access to XenCenter, or it decides it doesn't want to play, it's always a good idea to bring your own ball.
xe vm-list
Grab the uuid for the VM you wish to modify.
xe vm-param-set -uuid=<uuid> -memory-static-min=1024MiB
xe vm-param-set -uuid=<uuid> -memory-dynamic-min=1024MiB
xe vm-param-set -uuid=<uuid> -memory-static-max=1024MiB
xe vm-param-set -uuid=<uuid> -memory-dynamic-max=1024MiB
You will most commonly use MiB to specify the memory size.
My most common reason for setting this is the Windows 7 template sets the minimum RAM to 2GB, which IS the recommended minimum, but obviously not needed, especially if the VM is doing primarily lightweight testing (testing an install, etc.).
xe pool-enable-external-auth auth-type=AD service-name=<domain.com> config:user=<username> config:pass=<password>
xe pif-list host-name-label=<hostname> management=true
xe pif-param-set uuid=<uuid> other-config:domain=domain.com
reboot
hostname -d -v
Should show the search domains at the bottom.
Alternatively:
cat /etc/resolv.conf
So trying to boot off PXE on a XenServer VM seems to VERY frequently cause problems. I finally figured out how to work around the issue.
When booting from network (you probably need to bump network boot up above the "will not boot" line) hit Ctrl+B when it says to bring up the gPXE command line. Then do the following.
- dhcp net0 (or whatever adapter you want to use)
- config
- set "next-server" to the tftp server location (this is where all your boot images are) use the IP ot hostname.
- set "filename" to the path to the correct .com file. In my case I had to bypass the OSChooser and set the path to Boot/x64/wdsnbp.com
- Ctrl+X
- autoboot
- You should see it load the image and continue.
Note that you NEED to know the location where the images are stored and be able to see them so you know what file to point it to. If you can't figure it out, start pointing it to every .com you can find lol.
Also beware that on reboot these settings are NOT saved. Which is annoying. But hey, it beats flat out not being able to RIS.
A quick How-To: on adding a RAID array as an SR in XenServer, the version I personally used was 5.6 but 5.5 and 5.0 should be identical.
Steps to create an SR in a Xenserver.
Locate the RAID array partition.
cat /proc/partitions
This returns a list of all partitions, find the RAID array and make note of it's name (sda, sdb, sdx, etc.).
Now locate the disk-id.
ll /dev/disk/by-id
This lists disk ID's, look for the ID that matches the partition name from the previous step.
Obtain the XenServer host-uuid, we need this because we need to specify the XenServer as the host to attach the SR to in the next step.
xe host-list
Create the SR.
xe sr-create content-type=user device-config:device=/dev/<sdx> host-uuid=<host-uuid> name-label=”RAID Array” shared=false type=lvm
You should now be able to see (and use) your RAID array in XenCenter.