dalgibbard / citrix_xenserver_patcher

Auto / Manual Patching tool for Citrix XenServer Boxes
Do What The F*ck You Want To Public License
142 stars 45 forks source link

Unmount Ignores User + Matches non-CDROM disks #33

Open thowden opened 9 years ago

thowden commented 9 years ago

Hi,

To start, thanks for this utility, it has helped enourmously for my Xen environment.

I am now running patcher.py on an HP DL360 with Xen 6.2 with one VM only. I've tried with the VM powered up and down but no difference. Responding yes or no to auto-unmount gives the same answer, i.e. it seems to be forcing unmount even if told not to. I have yet to examine python code.


Example output with Y for yes to auto-umount

CD images are currently mounted to one or more VMs. These must be unmounted before starting the patching process.

Would you like to auto-umount these now? [y/n]: y

Unmounting CD Images from VMs

An error occured when attempting to unmount the CD Images. Error is: Operation could not be performed because the drive is empty vbd: 4986acf4-2830-8e6d-973f-f6387c2c08e7

Please manually unmount, and run the patcher again.


Example output with N for no to auto-umount

CD images are currently mounted to one or more VMs. These must be unmounted before starting the patching process.

Would you like to auto-umount these now? [y/n]: n

Unmounting CD Images from VMs

An error occured when attempting to unmount the CD Images. Error is: Operation could not be performed because the drive is empty vbd: 4986acf4-2830-8e6d-973f-f6387c2c08e7

Please manually unmount, and run the patcher again.


mount shows as: mount /dev/cciss/c0d0p1 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw) none on /dev/shm type tmpfs (rw) /opt/xensource/packages/iso/XenCenter.iso on /var/xen/xc-install type iso9660 (ro,loop=/dev/loop0) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)


umount /var/xen/xc-install does umount the only .iso listed above


xe vbd-list uuid ( RO) : 4986acf4-2830-8e6d-973f-f6387c2c08e7 vm-uuid ( RO): 572656b5-3e05-e864-1f25-c34ed0a06b58 vm-name-label ( RO): MyServerName vdi-uuid ( RO): empty ( RO): true device ( RO): hdd Appears to show that the vbd is not available.


I suspect it may be a raid rebuild in progress rather than a removable drive issue and I'll check it again in a few hours to see if the drive becomes available.

The purpose of the post is to check if there is anything in the patcher.py that needs to be reviewed to address the Y / N umount getting the same response. I would have expected N to just move on.

Thanks again.

Tony

dalgibbard commented 9 years ago

This is an interesting one... The code itself should come to a hard stop if the user chooses 'no' as any mounted disks on VMs have been known to break the application of updates. What it defintiely shouldn't do is:

Definitely a bug. Marking as so.

dalgibbard commented 9 years ago

Got the fix for this in my dev tree at present. Shouldn't be long till this is committed. Better late than never!

dalgibbard commented 9 years ago

Closing this now :)

thowden commented 9 years ago

Hi

I've just updated patcher on one of my servers and I am still seeing a similar error.

An error occured when attempting to unmount the CD Images. Error is: Operation could not be performed because the drive is empty vbd: 4986acf4-2830-8e6d-973f-f6387c2c08e7

I think there is nothing mounted on dom(0) that appears to relate:

mount

/dev/cciss/c0d0p1 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

So it must be the VM on the server and short of deleting the actual drive from the VM (or shutting down the VM, which I have not tried as yet - production environment).

But if the drive is "empty" then what is the issue.

Once again an answer of Yes or No, gives the same error result which says that umount cannot be used for this CD drive.

Thoughts ?

Thanks Tony

dalgibbard commented 9 years ago

Try adding the -D argument to enable debugging. It should be a little more verbose about what it's finding.

Suggestion; pipe it into tee to produce a log file:

./patcher.py -D | tee /tmp/patcher.log
thowden commented 9 years ago

Hi

On a different topic, I noted this error with removing a file:

Downloading: XS62ESP1020.zip Download Size: 115985387 Bytes 115985387 [100.00%] Applying: XS62ESP1020 Uncompressing... Internal Upload... Completed: 6057cfe5-811d-46f1-82e1-6da737a0a038

Applying Patch 6057cfe5-811d-46f1-82e1-6da737a0a038 Couldn't find file: XS62ESP1020-src-pkgs.tar.bz2 - Won't remove it. Cleaned patch data for UUID: 6057cfe5-811d-46f1-82e1-6da737a0a038

Tony

dalgibbard commented 9 years ago

Yup that's fine; we check to see if the source package file has been left behind, and clean it up if it is. As the file wasn't found, there's nothing to clean.

Though, do check your working directory to make sure there's no *-src-pkg.tar.bz2 files present in case something went wrong in the filename detection. :)

thowden commented 9 years ago

From the debug log, nothing different to what I am seeing already (as per below). The log includes a long list of every patch file applied and to be applied, not sure if that is relevant ? I have 4 dom(0) hosts and 2 have run ok, and 2 have this vbd issue just with different UUID's and both are showsn as hdd. Both show the vdi-uuid as . I have tried full shutdown and restarts. Both hosts have in common: only 1 VM Windows server 2008 and 2012. Both completed hosts have in common multiple VM's of Windows and Linux platforms. Not that I think 1 VM vs many is the issue, but I am looking for commonalities.


NOTE: Installation of these items will require a reboot! You will be prompted to reboot at the end. Would you like to install these items? [y/n]: CD Check Output: CD 0 VBD: uuid ( RO) : 4986acf4-2830-8e6d-973f-f6387c2c08e7 vm-name-label ( RO): MyServerName empty ( RO): true userdevice ( RW): 3

CD images are currently mounted to one or more VMs. These must be unmounted before starting the patching process.

Would you like to auto-umount these now? [y/n]: Unmounting CD Images from VMs

An error occured when attempting to unmount the CD Images. Error is: Operation could not be performed because the drive is empty vbd: 4986acf4-2830-8e6d-973f-f6387c2c08e7

Please manually unmount, and run the patcher again.


From the console

xe vbd-list

uuid ( RO) : 4986acf4-2830-8e6d-973f-f6387c2c08e7 vm-uuid ( RO): 572656b5-3e05-e864-1f25-c34ed0a06b58 vm-name-label ( RO): MyServerName vdi-uuid ( RO): empty ( RO): true device ( RO): hdd


Double checking everything, the VM on this host has 2 x VHD's being hda and hdb and a DVD physical drive. hdd and the rogue UUID does not appear to exist other than in the listing. Just not clear on how to safely remove it or clarify what it actually relates to.

cheers Tony

dalgibbard commented 9 years ago

OK I see now; seems safe enough to ignore devices which have a status of empty (RO): true

Will workaround this in code.

dalgibbard commented 9 years ago

Managed to reproduce this by:

I guess the ideal fix here would be to build an array of CD devices located, strip any set to empty: true and any non-CDROM devices from the array, and then iterate through each one to unmount as required. That's a fairly big code change required though, for something which isn't really much of an issue :)

For now, I've committed a change which introduces a quick 'heads-up' to the end user, and allows the user to continue after reviewing the reported errors; the output will change to the following:

CD images are currently mounted to one or more VMs.
These must be unmounted before starting the patching process.

Would you like to auto-umount these now? [y/n]: y

Unmounting CD Images from VMs...

An error occurred when attempting to unmount the CD Images:
"Operation could not be performed because the drive is empty
vbd: 4986acf4-2830-8e6d-973f-f6387c2c08e7"

** NOTE: ** Errors due to non-CDROM devices, or Empty drives can be ignored.

Would you like to continue anyway? [y/n]:

At least for now we can ignore and continue :)

thowden commented 9 years ago

Hi Darren,

Thanks for working through this. I agree with the synopsis and that it is an issue that can be ignored for the purpose of processing patches.

Also I have downloaded the latest release and it is working right now on the two servers that had this issue as per the new option to "continue anyway".

cheers Tony

thowden commented 9 years ago

Hi Darren

Just confirming that both servers have now been successfully patched with the new release of patcher.py

Thanks again for your assistance and for this script.

Excellent work !

cheers Tony www.wrenmaxwell.com.au

dalgibbard commented 9 years ago

Good to hear! I'll hold this open with the view to one day changing the code to handle this without user intervention.