Hi guys. Thank you both for your suggestion.
I did not know one can attach root disk from offline instance to another running instance using CS. If I were to choose, i would go with the XenCenter method, because I really do not feel comfortable with playing on live clustered LVM over ISCSI setup. Actually it turned out, that it was easier just rolling a new instance and import data from offsite backup. The owner installed grub to /dev/xvda, where filesystem resides (no partitions). I guess it could be fixed, but one would have to fsck FS first. Tnx again and Regards, F. On 21 Jun 2015, at 16:49, Tim Mackey <tmac...@gmail.com> wrote: > If that process didn't work, here's another (using XenCenter) > > 1. Stop the original VM (the one you want to fix). Note it's VM name and > find it in your XenServer resource pool. > 2. Create a new VM within CS and start it. Note the VM name and find it > within your XenServer resource pool > 3. On the original VM, give the root disk a readily identifiable > description (it'll help in this process) > 4. Detach the root disk from the original VM > 5. Find the original root disk and attach it to your second VM and note the > device id assigned to it > 6. Login to the second VM and mount the original root disk > 7. Fix grub > 8. Unmount the original root disk > 9. Detach original root disk from the second VM > 10. Reattach the original root disk to the original VM > 11. Start the original VM. > > At this point everything should be working (provided grub was the issue). > > While I've given the process using XenCenter, it can be done with CLI. > It's just a bit harder to keep track of the correct uuids using the CLI. > Note that in all of this, if you need to move VMs from one host to another, > that's fine, just make certain they are back on their original hosts when > you're done lest CS get confused. > > -tim > > On Sun, Jun 21, 2015 at 7:14 AM, Stephan Seitz < > s.se...@secretresearchfacility.com> wrote: > >> Hi, >> >> on XenServer I'ld expect your SR containing *.vhd files. You could use >> the cli "xe" command to determine which file is attached. Maybe this >> info can also be seen in the gui. >> >> Here's a short walkthrough, how to access vhd files: >> http://wiki.xen.org/wiki/Mounting_a_.vhd_disk_image_using_blktap/tapdisk >> >> If your vhd file contains partitions, you could do a >> kpartx -a /dev/xen/.... >> to get >> /dev/mapper/blktap0p[0....n] >> >> Depending on your guest OS, e.g. If there's LVM or dm-crypt etc... >> inside the following steps vary. >> >> Just use standard linux tools to mount / pvscan / cryptsetup / ... >> the /dev/mapper/blktap... partitions. >> >> With additional bind-mounts of /sys, /proc, /run, /dev, /dev/pts you >> should be able to chroot into the filesystem and perform the necessary >> tasks. >> >> Just as a note: Be careful, to do this only exclusively, say with the >> respective VMs powered-off. Also, double check to umount / pvchange >> -n / ... every layer you've built. Also kpartx -d the partitions and >> unmap the blktap before trying to boot the VM. >> >> Good luck! >> >> - Stephan >> >> >> Am Sonntag, den 21.06.2015, 12:43 +0200 schrieb France: >>> Hi, >>> >>> after upgrading Ubuntu Linux, the system does not boot, probably because >> of wrong grub config format: >>> ( errorInfo: [Traceback (most recent call last):, File >> "/usr/bin/pygrub", line 808, in ?, fs = fsimage.open(file, >> part_offs[0], bootfsoptions), IndexError: list index out of range, ]) >>> >>> How can I get access to disk of this VM, to fix the grub file by hand >> and try to restart it? >>> I have CS 4.3 on XS 6.0.2 with ISCSI disk for virtual instances. >>> >>> Tnx. >>> France. >> >>
