@scottalanmiller said

Like an LVM system with just one block device, one VG and on LV taking up the whole space. The layers are still there.

Why would you bring up that reference?

(INSIDE JOKE.)

Oooh, I think I am getting somewhere!

lrwxrwxrwx  1 root root   64 Jul 11 13:01 log -> /run/sr-mount/cbe8175f-43b3-3a64-cdac-3c1475aa2d01/xenserverlogs

The one thing to note is that in my system, XS7 used my entire array for VM storage. I boot off USB and only have one presented drive (Raid 5 SSD) in the server.

After discussing with @scottalanmiller it was determined it was probably OK to create a directory alongside the .VHD files in SR-Mount and store the logs there.

So far, so good. Nothing has imploded.

I'm leaning towards something wacky, because even if the SR was detached for some reason, why would the networking not work as well?

@travisdh1 said

Something is wrong with that first lsblk output. System has crashed/been corrupted by something.

It came back "normal" after a reboot, but obviously a lot of functionality was hosed.

I tried running a dd on this machine the other day, and it was taking forever.

After about 90 minutes I stopped it, and it had only done 15GB thus far. (Of a 64 GB stick.)

Possible maybe the USB stick was going bad, and finally gave up the ghost?

Is it possible cancelling (^C) dd would have done anything to the source USB stick?

@scottalanmiller said

Sounds like the DM device has died perhaps beneath the LV.

Since the USB stick showed all those weird characters, wouldn't it be more probable that the USB stick died, and not the hard drive that LV was on?

@Ajin said

I was just testing moving the VM to the new storage , moved the VM to the new storage , changed the mac id and it works good , Now i can take snap since the vm resides in the new storage with enough space for snapshot

It's awesome when it works like that, right?

@DustinB3403 said

That the USB has something wrong with and needs to be replaced.

Odd because it is brand new, and from Samsung.

It's almost like it went crazy for a bit, the data got corrupted, but then now it looks OK again, just doesn't work.

Ghost in the machine...

I took that USB drive out of the XS, stuck it into my Windows machine, reformatted it, and ran a CHKDSK on it, checking all sectors.

Nary an issue.

Maybe just a fluke and the drive is really OK? Or trash it?

I'm leaning towards trashing it.

Today I rebuilt the crashed XS7. Installed XS7 to a new USB. Once XS was set up, I stopped the mounting of /var/log and redirected it to a folder on the VM SR. Then I set up 2 test VMs on the XS7. Everything was working fine.

Then guess what? Same issue happened. I rebooted the XS, and it crashed in the exact same way. No network and the SR had been unmounted.

What the hell is going on? At this point I am ruling out hardware. Is it possible putting anything on the VM storage LV crashes XS? Is it possibly a bug?

What is this?????

@travisdh1 said in How to Stop XenServer from Mounting /var/log:

@BRRABill The only thing that springs to mind is making sure the volume group the logical volume sits on is ok. It should be with the logical volume being ok. The other thing is making sure /var/log is mounting via fstab correctly (df). Kinda grasping at straws at the moment.

The VG/LV should be OK. They are brand new and work fine until the change.

I do not mount /var/log ... just symlink to it. Is that incorrect? It is originally in fstab because they mount it to a partition on the boot device.

@travisdh1 said

Right. In this case what they did actually does make sense. The drive containers were each created as their own LV.

You mean what XS did makes sense?

@scottalanmiller said in Cloning XenServer on USB or SD:

I assume that there is only one partition. You can check yours but there should not be multiple partitions.

This is how XS7 sets it up, at least...

sdb                                                                 8:16   0  74.5G  0 disk
├─sdb1                                                              8:17   0    18G  0 part /
├─sdb2                                                              8:18   0    18G  0 part
├─sdb3                                                              8:19   0   512M  0 part
├─sdb5                                                              8:21   0     4G  0 part /var/log
└─sdb6                                                              8:22   0     1G  0 part [SWAP]

I'm not trying to be argumentative. It's just that we're recommended X and Y, but it seems that they don't seem to work.

I'd like to come up with a set guideline of ... hey XS is great off USB, but THIS is what you have to do, and anything will crash your system.

It just seems like we are having a lot of system crashes or "yeah I tried this in my home/test lab and it didn't work" situations.

@scottalanmiller said

And I think an important lesson for newbies is... while running from SD is great and a best practice for experts, if you are not an expert on XS, just install to the local the disks. Keep the deployment simple.

Well, in my defense, it was stated pretty repeatedly that NOT installing XS to SD/USB was something a newbie would do, not the other way around.

XS themselves basically say treat it as an appliance. Install it and don't mess with it.

@coliver said

You said right here, this may be a different topic all together. That they recommend that you restore the host by installing it from the media. That would imply that you don't backup the host itself at all.

Then the next page they say
"Citrix recommends that you frequently perform as many of the following backup procedures as possible to
recover from possible server and/or software failure."

And go into the backups I mention.

This only works for the original machine, though. But I imagine that you could replicate this on a new XS (by attaching the SR and restore metadata) pretty "easily".

@PRPL said in Converting to a virtual environment:

wow .... errr... have I opened-up a can of worms here ?

And also backed up the statement of @JaredBusch

Further on there is this. Perhaps this answers your question, @scottalanmiller

"Because the privileged control domain is best left as installed, without customizing it with
other packages, Citrix recommends that you set up a network boot environment to cleanly
perform a fresh installation from the XenServer media as a recovery strategy. In many cases
you will not need to backup the control domain at all, but just save the pool metadata (see
Section 8.9.1, “Backing up Virtual Machine metadata”). This backup method should always
be considered complementary to backing up the pool metadata."

I take this as, if you leave it "as installed" there is no need to backup the host.

@scottalanmiller said in Converting to a virtual environment:

@BRRABill said in Converting to a virtual environment:

You could throw Linux on a spare machine and accomplish what you are looking for pretty cheaply.

And that's why USB drives are never used... there is always a better, simpler way.

IF you have a spare machine sitting around.

(Yes, I am kidding.)

I did basically the same thing, and am hoping it works. I used XS instead of VirtualBox, though.

I had a fresh Windows 8 FPP key.

I did a fresh install of Windows 10, and used this Windows 8 key, and it activated.

I later tried reusing the key, and it said it was used on another PC.

So I am assuming (assuming, assuming) it worked.

I understand I will have to use the phone option down the road, but hopefully this key is activated in Windows 10.